skip to content

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