Abstract Classes in Java: Incomplete Types and Partial Implementation

An abstract class is a class you are not allowed to instantiate but are very much allowed to inherit from. That is the whole rule, and it sounds arbitrary until you notice what it prevents: an object whose behaviour has a hole in it.

Inside one abstract class you can freely mix complete code and bare declarations. Fields work. Constructors run. Concrete methods execute exactly as written. Alongside all of that you may declare methods with a name, a return type, and parameters but no body at all. Those are abstract methods, and each one is a promise the class makes and refuses to keep itself.

abstract class Notification {
    protected final String recipient;
    // state, fully usable
    protected Notification(String recipient) {
        this.recipient = recipient;
        // constructor, runs via super(...)
    } void log() {
        // concrete, works today
        System.out.println("to " + recipient);
    } abstract void send();
    // signature only, no body
}

So the type is not empty, it is unfinished. Enough of it is missing that new Notification() would hand you an object that cannot do its own job, so the compiler refuses:

Notification n = new Notification();
// error: Notification is abstract; cannot be instantiated

Declaring a reference of that type is completely fine. Only construction is blocked, which is why Notification n = new EmailNotification(...) compiles without complaint.

Partial implementation is the reason abstract classes exist, and the term is worth taking literally. Some of the type is implemented; the rest is left open on purpose. The parent owns whatever is genuinely identical across the family, and the children own whatever actually varies.

In the example above, recipient and log() are the same for every channel, so they are written once in the parent. send() is not the same for an email than it is for an SMS, so it stays abstract. Each child fills in its own version:

final class EmailNotification extends Notification {
    private final String smtpServer;
    EmailNotification(String to, String smtpServer) {
        super(to);
        // the parent constructor still runs
        this.smtpServer = smtpServer;
    } @Override void send() {
        System.out.println("connecting to " + smtpServer);
    }
}

The payoff appears at the call site. One array holds both kinds, one loop processes them, and not one line of that loop knows which type it is holding:

for (Notification n : queue) {
    n.log();
    n.send();
}

Without the shared parent you would duplicate the recipient field and the logging in every class, and the loop would need an instanceof test. The abstract class moves that decision to compile time, where it costs nothing at run time.

One row deserves emphasis. A method cannot be both abstract and static, and javac says so plainly:

abstract class A {
    abstract static void m();
}// error: illegal combination of modifiers: abstract and static

The same error appears for private abstract and final abstract. The reasoning is consistent: a static method belongs to the class rather than to instances, a private one is not inherited, and a final one is locked. An abstract method has to be something an object can actually do and something a child can actually replace.

If a subclass does not implement every inherited abstract method, it must declare itself abstract, and the obligation passes on to its children. It is a to-do list that shrinks as you descend, and nothing is allowed off the hook until some concrete class clears it.

abstract class Shape {
    abstract double area();
}abstract class Polygon extends Shape {
    // area() still open
    abstract boolean isConvex();
}final class Rectangle extends Polygon {
    // both closed
    private final double width;
    private final double height;
    Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    } @Override double area() {
        return width * height;
    } @Override boolean isConvex() {
        return true;
    }
}

Try to instantiate the middle class and the compiler stops you again, this time naming the specific method:

class Middle extends Shape {
}Polygon p = new Middle();
// error: Middle is not abstract and does not override
//        abstract method area() in Shape

Note that Polygon being abstract is not what causes that error. It is that Middle is concrete while leaving a method open.

The canonical use of an abstract class is to fix a sequence in the base and leave only the varying steps open. Mark the orchestrating method final so a subclass cannot reorder or skip the steps, then declare the steps themselves as abstract.

abstract class ReportGenerator {
    public final void generate() {
        // the skeleton, locked
        loadData();
        format();
        System.out.println("report complete");
    } protected abstract void loadData();
    // the blanks to fill
    protected abstract void format();
}

Because generate() is final, every subclass runs the same algorithm in the same order, and the only freedom is in the two hooks. This is the strongest argument for choosing an abstract class over an interface: an interface can demand that loadData() exists, but it cannot supply the generate() that calls it, and it cannot stop a subclass from reordering its own steps.

Compare that with an method override that is left empty. An empty body compiles happily and produces a silent no-op at run time:

class Broken extends ReportGenerator {
    @Override protected void loadData() {
    } // compiles, does nothing
    @Override protected void format() {
    }
}

Declaring the hooks abstract instead turns that silent no-op into a compile error the moment somebody forgets. That is the whole argument for preferring abstract over an empty concrete method.

A workable rule: use an interface to say what a thing can do, and an abstract class to say what a thing is and how the shared part works. The decisive question is whether the subclasses need shared state or shared constructor logic. If they do, no amount of interface cleverness will supply it, because interfaces hold no per-object state and define no constructors.

The two combine freely, and the order matters for super:

interface Printable {
    void print();
}abstract class Document implements Printable {
    protected int pageCount;
    void printHeader() {
        System.out.println("pages: " + pageCount);
    } // print() is still abstract here, and that is allowed
}

This surprises nearly everyone the first time. An abstract class may declare a constructor, and it is not contradictory. The constructor exists for the subclasses, not for the abstract class itself, and it is reached through super(...).

abstract class DatabaseConnection {
    protected final String url;
    DatabaseConnection(String url) {
        this.url = url;
    } abstract boolean testConnection();
}final class MySqlConnection extends DatabaseConnection {
    MySqlConnection() {
        super("jdbc:mysql://localhost:3306/app");
    } @Override boolean testConnection() {
        return url.startsWith("jdbc:mysql");
    }
}

The parent constructor always runs before the child body, so shared state is initialised exactly once and every subclass passes through the same validation. What you still cannot do is write new DatabaseConnection(...).

One ordering rule catches people out constantly: super(...) must be the first statement in a constructor, before any field assignment of your own.

abstract class Loader {
    protected final String path;
    Loader(String path) {
        this.path = path;
    } abstract void open();
}final class Broken extends Loader {
    private final int retries;
    Broken(String path, int retries) {
        this.retries = retries;
        super(path);
    } // error: call to super must be first statement in constructor

Move the super(path) call to the top and the class compiles. Getting this order wrong is the single most common compile error in any class that extends something.

Reach for an abstract class when several subclasses genuinely share data or code and you want that sharing enforced by the compiler rather than by team discipline. The Notification family above is exactly that shape.

Skip it when the only thing in common is a method name. Two unrelated classes that each happen to have a send() do not need a parent, and duplicating three lines is cheaper than an inheritance tree nobody asked for.

Signs you are forcing it:

• The abstract class has exactly one subclass and no second one is planned.
• You added a parent only to satisfy a rule of thumb.
• The parent holds no real state, and only method names are being shared. That is an interface wearing a hat.

A useful test: if you cannot complete the sentence "every subclass needs..." with at least one field or one real method, an interface is the better tool.

Frequently Asked Questions

Can we instantiate an abstract class in Java?

No. new AbstractClass() is a compile-time error, reported as "X is abstract; cannot be instantiated". The check happens before the program runs, because the type is deliberately incomplete. To obtain an object, create a concrete subclass and instantiate that, or return one from a factory method.

What is partial implementation in Java?

It is when a class inherits behaviour from a parent and leaves the rest for its children to finish. An abstract class is the tool for it: concrete methods hold the shared part, abstract methods mark what each child must write. In the example above, Notification shares recipient and log() while leaving send() and channel() open.

What is the difference between an abstract class and an incomplete class?

Java has no separate "incomplete class" construct. "Incomplete type" is a descriptive phrase for an abstract class, or for a concrete class whose parent left a method unimplemented. The compiler's job is to guarantee the incompleteness is always resolved somewhere before any object exists.

Can an abstract class have a constructor?

Yes. The constructor initialises state shared by every subclass and is invoked from them through super(...). It is never called on the abstract class itself, because that class cannot be instantiated. It is exactly the feature an interface cannot offer.

Can an abstract class have zero abstract methods?

Yes, and it compiles. The abstract keyword on its own blocks direct construction, which is useful when a class should only ever be obtained through a factory or a static builder.

What happens if a subclass does not implement all abstract methods?

The compiler reports that the class is not abstract and does not override the named method, unless the subclass is itself declared abstract. The obligation then passes to its own subclasses until some concrete class closes every gap.

Why can an abstract method not be private or static?

Because a private method is not inherited, so no child could ever see or replace it, and a static method belongs to the class rather than to instances, so there is no per-object behaviour to supply. javac rejects both as an illegal combination of modifiers.

Is abstract slower than a concrete class at run time?

No. There is no runtime check involved. The completeness requirement is enforced entirely at compile time, and the resulting object behaves exactly like any other. The only cost is a slightly deeper hierarchy, which is irrelevant next to the duplication it removes.

Should I use an empty method body instead of an abstract one?

No. An empty body compiles without complaint and produces a silent no-op at run time, which is far more expensive to find than a compile error. Declare the method abstract so a forgetful subclass fails the build immediately.

Can an abstract class implement an interface?

Yes, and it is common. The abstract class can implement the interface without providing every method, since it is itself abstract and cannot be instantiated anyway. Each concrete subclass then inherits the remaining obligation and must complete it.