Runtime Polymorphism

Two kinds of type

Every object reference in Java has two types.

Subsystem s = new Drivetrain();

The declared type is Subsystem — what the compiler sees, and what decides which methods you are allowed to call. The actual type is Drivetrain — the real object, and what decides which version of a method actually runs.

Runtime polymorphism is that second part: the choice of implementation happens while the program runs, based on the real object, not on what the variable was declared as.

A worked example

abstract class Subsystem {
    abstract void periodic();

    void report() {
        System.out.println(getClass().getSimpleName() + " reporting");
    }
}

class Drivetrain extends Subsystem {
    @Override
    void periodic() {
        System.out.println("updating drive motors");
    }
}

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

Now a single loop drives every subsystem without knowing which is which:

List<Subsystem> subsystems = List.of(new Drivetrain(), new Intake());

for (Subsystem s : subsystems) {
    s.periodic();       // runs Drivetrain's or Intake's version as appropriate
}

Output:

updating drive motors
checking intake sensor

The loop contains no if checking the type. Each object supplies its own behaviour, and Java routes the call.

Always use @Override

class Intake extends Subsystem {
    @Override
    void periodic() { ... }
}

@Override is optional to the compiler but you should treat it as mandatory. It asks the compiler to verify that you really are overriding something. Misspell the name or get a parameter type wrong, and you have quietly written a new method that nothing ever calls:

class Intake extends Subsystem {
    void periodick() { ... }      // typo — compiles fine, never runs
}

With @Override, that becomes a compile error instead of a silent bug.

Interfaces versus abstract classes

Both let you write code against a type rather than a specific class.

A rough rule: if you are describing what something can do, use an interface. If you are sharing actual implementation and fields between related classes, use an abstract class.

interface Stoppable {
    void stop();
}

class Drivetrain extends Subsystem implements Stoppable {
    @Override public void periodic() { ... }
    @Override public void stop() { System.out.println("brakes on"); }
}

A class can extend one thing and implement several, which is why capabilities are usually interfaces.

What is not polymorphic

Two things behave differently from what you might expect.

Fields are not overridden. They are chosen by the declared type:

class Parent { String name = "parent"; }
class Child extends Parent { String name = "child"; }

Parent p = new Child();
System.out.println(p.name);          // "parent" — not "child"

This is called field hiding, and it is a good reason to keep fields private and expose them through methods, which are polymorphic.

Static methods are not overridden either. They are resolved by the declared type at compile time, so a static method never dispatches on the actual object.

Overloading is a different thing

The two words look similar and are frequently confused.

Only overriding is polymorphism. See Method and Constructor Overloading for the other one.

Checking the actual type

Occasionally you genuinely need to know what you have:

for (Subsystem s : subsystems) {
    if (s instanceof Stoppable stoppable) {     // pattern matching, Java 16+
        stoppable.stop();
    }
}

The variable after the type is declared and assigned in one step, so no separate cast is needed.

// this defeats the purpose
if (s instanceof Drivetrain) {
    ((Drivetrain) s).driveForward();
} else if (s instanceof Intake) {
    ((Intake) s).runIntake();
}

Next

Review