Abstract Classes and Methods

A class that is deliberately incomplete

Sometimes a base class knows that something must happen but not how. Every subsystem needs a periodic update, but what “update” means depends entirely on which subsystem it is.

You could give the parent an empty method and hope subclasses remember to override it:

class Subsystem {
    void periodic() { }         // does nothing — easy to forget to override
}

That compiles, and a subclass that forgets silently does nothing at all. An abstract method makes it a compile error instead:

abstract class Subsystem {
    protected final String name;

    Subsystem(String name) {
        this.name = name;
    }

    abstract void periodic();       // no body — subclasses must supply one

    void describe() {               // ordinary method — inherited as usual
        System.out.println("subsystem: " + name);
    }
}

An abstract method declares a signature and ends with a semicolon instead of a body. Any concrete subclass must implement it:

class Intake extends Subsystem {
    Intake() { super("intake"); }

    @Override
    void periodic() {
        System.out.println("checking intake sensor");
    }
}

Omit periodic in Intake and the code will not compile. The requirement is enforced rather than hoped for.

Abstract classes cannot be instantiated

Subsystem s = new Subsystem("thing");   // compile error
Subsystem s = new Intake();             // fine

This is the other half of the point. A Subsystem with no periodic is not a usable object, so Java refuses to create one. You can still use the type as a variable, parameter, or return type — you just cannot construct it directly.

Mixing abstract and concrete

This is what abstract classes offer that interfaces historically did not: real fields, constructors, and finished methods alongside the abstract ones.

abstract class Subsystem {
    protected final String name;
    private boolean enabled = false;

    Subsystem(String name) {
        this.name = name;
    }

    // concrete — shared by every subclass
    void enable()  { enabled = true; }
    void disable() { enabled = false; }
    boolean isEnabled() { return enabled; }

    // abstract — each subclass decides
    abstract void periodic();

    // concrete, but built on the abstract part
    final void update() {
        if (enabled) {
            periodic();
        }
    }
}

update is interesting: it is finished code in the parent that calls a method the parent has not written. The parent controls when the work happens; the subclass controls what the work is.

Marking update as final means subclasses cannot change that ordering — they can only fill in periodic. That combination, a fixed skeleton with subclass-supplied steps, is a common and useful shape.

Partial implementations

An abstract class may extend another abstract class and implement only some of the inherited abstract methods, leaving the rest for further subclasses:

abstract class Subsystem {
    abstract void periodic();
    abstract void stop();
}

abstract class MotorSubsystem extends Subsystem {
    protected final Motor motor;

    MotorSubsystem(Motor motor) { this.motor = motor; }

    @Override
    void stop() {                    // supplied here for all motor subsystems
        motor.set(0);
    }
    // periodic() left abstract — still each subclass's job
}

class Intake extends MotorSubsystem {
    Intake(Motor motor) { super(motor); }

    @Override
    void periodic() { motor.set(0.6); }
}

MotorSubsystem is still abstract because periodic remains unimplemented — but it has removed duplication for everything below it.

Abstract class or interface

Both let you write code against a type rather than a specific class. The distinction has narrowed since interfaces gained default methods, but real differences remain.

A template method

The update/periodic split above has a name — the template method pattern. The parent defines the sequence; subclasses fill in steps.

abstract class AutoRoutine {
    // fixed sequence, subclasses cannot reorder it
    final void run() {
        initialise();
        while (!isFinished()) {
            step();
        }
        cleanUp();
    }

    void initialise() { }             // optional hook, default does nothing
    abstract void step();             // required
    abstract boolean isFinished();    // required
    void cleanUp() { }                // optional hook
}

Distinguishing required steps (abstract) from optional hooks (concrete, empty) is deliberate. A subclass must supply step and isFinished; it may ignore initialise and cleanUp.

Next

Related