skip to content

Abstract Classes

Abstract classes and abstract methods: no instantiation, but constructors, fields and concrete methods are all allowed. Interviewers ask what an abstract class can hold that an interface cannot, and why you would want that.

part ofJavaoverview, primer and where to startread it →
on this pageshow

questions

5

How do you declare an abstract method, and what obligations does it place on subclasses?

level: juniorimportance: must knowfreq 70%

answer

  1. abstract + signature + semicolon, no body
  2. only in abstract class or interface
  3. first concrete subclass must override
  4. cannot be private, static, or final
  5. compiler enforces the contract

basics

~20 s

An abstract method is written with the abstract keyword and no body — just a signature ending in a semicolon. Any concrete (non-abstract) subclass must override it and supply a real body, or it won't compile.

solid answer

~40 s

You declare an abstract method by marking it abstract and giving it a signature with no body, terminated by a semicolon instead of braces: `abstract double area();`. It only legally appears inside an abstract class (or as the implicit form in an interface). The obligation it creates: the first concrete subclass in the chain must override it with a matching signature and provide a body. If a subclass leaves it unimplemented, that subclass must itself be declared abstract, pushing the obligation further down. Abstract methods cannot be private (subclasses couldn't see them to override), cannot be static (static methods aren't overridden), and cannot be final (final forbids overriding). The point is to define a contract — 'this operation exists and varies per subclass' — while deferring the implementation.

go deeper

for a junior

Writes the syntax correctly (abstract keyword, semicolon, no body) and knows a subclass must fill it in.

for a middle

Explains the deferral chain (abstract subclass may skip; first concrete one must override) and the private/static/final restrictions with reasons.

for a senior

Connects abstract methods to Template Method / skeletal implementations and overriding rules (covariant returns, exception narrowing).

for a principal

Reasons about contract design — minimizing the abstract surface, the fragility of base classes that call their own abstract hooks during construction, and migration to default methods/composition.

## Anatomy of an abstract method A normal Java method has a **signature** (modifiers, return type, name, parameter list) followed by a **body** in braces: ```java double area() { return 3.14; } ``` An **abstract method** keeps the signature but replaces the body with a single semicolon, and adds the `abstract` keyword: ```java abstract double area(); ``` This declares 'there exists an operation called `area` that takes no arguments and returns a double, but I am not saying how it works.' It is a *promise of behavior* with no implementation. ## Where it can appear An abstract method may only live inside an **abstract class** (a class marked `abstract`) or an **interface** (where method declarations are implicitly abstract unless marked `default`/`static`). Putting an abstract method in a normal class is a compile error, because the class would then be instantiable yet have a method with no behavior. ## The obligation on subclasses When class `B extends A` and `A` has an abstract method, Java tracks whether `B` provides an implementation: - If `B` **overrides** the abstract method with a concrete body (matching signature), `B` can be a normal, instantiable class. - If `B` does **not** implement it, then `B` still has an inherited abstract method, so **`B` must itself be declared `abstract`**. The obligation is inherited and passed down the chain until some subclass finally implements it. This is what makes abstract methods a *contract*: the compiler guarantees that you can never create an object that has an unimplemented abstract method. **Overriding** means supplying a subclass method with the same name and parameters; the abstract method is the 'slot' the override fills. ## Modifier restrictions (and why) Abstract methods cannot combine with certain modifiers because the combinations are contradictory: - **`private`** — private members aren't visible to subclasses, so they couldn't be overridden. Contradiction. - **`static`** — static methods belong to the class, not an instance, and are *hidden*, not overridden via dynamic dispatch. An abstract static method has no one to implement it polymorphically. Contradiction. - **`final`** — `final` means 'cannot be overridden,' the exact opposite of abstract's 'must be overridden.' Contradiction. All three produce compile errors. ## Why this matters Abstract methods are the mechanism behind the **Template Method** pattern and 'skeletal implementations': the base class writes the overall algorithm in a concrete method and calls abstract 'hook' methods that subclasses fill in. The base controls the *structure*; subclasses control the *steps*.

  • Why can't an abstract method be private?
    Private members aren't inherited or visible to subclasses, so no subclass could ever override and implement it. An abstract method that can never be implemented is meaningless, so the combination is a compile error.
  • If A is abstract with method m(), and B extends A without implementing m(), is B legal?
    Yes, as long as B is also declared abstract. B inherits the still-unimplemented m(), so it cannot be concrete. The implementation obligation moves down to the first concrete subclass of B.

saying these in an interview costs you the question

  • Writing an abstract method with empty braces {} — that's a concrete no-op method, not abstract.
  • Saying every subclass must implement it — only the first *concrete* subclass must; abstract subclasses may defer.
  • Thinking abstract methods can be private or static.
  • Forgetting that an abstract method ends with a semicolon, not braces.

context

open as a page

What is an abstract class in Java, and what can it contain that a regular interface (historically) could not?

level: juniorimportance: must knowfreq 78%

basics

~20 s

An abstract class is a class marked with the abstract keyword that you cannot create objects from directly. It can mix finished methods with unfinished (abstract) methods that subclasses must complete. It can also hold normal fields and constructors.

open as a page

Why can't you instantiate an abstract class, yet it can still declare constructors and even fields — what role do those play?

level: middleimportance: should knowfreq 58%

basics

~20 s

You can't use new on an abstract class because it may have unfinished (abstract) methods, so the object would be incomplete. Its constructor and fields still exist to set up the shared state that subclasses inherit; the subclass constructor calls super(...) to run them.

open as a page

How do abstract classes enable the Template Method pattern, and why is a concrete method calling an abstract one the core mechanism?

level: seniorimportance: should knowfreq 52%

basics

~20 s

The abstract class writes the overall algorithm once in a concrete method, but leaves the varying steps as abstract methods it calls. Subclasses fill in only those steps. The base controls the order and structure; subclasses control the details.

open as a page

When should you choose an abstract class over an interface or a concrete class, and what are the long-term costs of exposing an abstract class in a public API?

level: principalimportance: nice to knowfreq 40%

basics

~20 s

Use an abstract class when subclasses share real state and implementation under a single 'is-a' hierarchy. Prefer an interface when you only need a contract or multiple inheritance of type. Exposing an abstract class in a public API locks you into its structure, so favor composition where you can.

open as a page