Java Polymorphism: One Interface, Many Forms

One Reference, Many Types

Polymorphism is the payoff of inheritance and interfaces. It means a single variable typed as a parent (or an interface) can hold an object of any subtype, and when you call a method on it, Java runs the version belonging to the object's actual class - not the version implied by the variable's declared type.

You have already seen the setup on the inheritance page: a subclass overrides a method from its parent. Polymorphism is what makes that override worth doing - it lets you write code against the general type and let each concrete object behave in its own way.

class Animal {
    String speak() { return "..."; }
}

class Dog extends Animal {
    String speak() { return "Woof"; }
}

class Cat extends Animal {
    String speak() { return "Meow"; }
}

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // a parent reference holding a child object
        Animal b = new Cat();

        System.out.println(a.speak());   // Woof
        System.out.println(b.speak());   // Meow
    }
}

Both a and b are declared as Animal, yet each prints its own sound. That choice happens at runtime based on the real object.

Dynamic Method Dispatch

The mechanism behind this is dynamic method dispatch: for an overridden instance method, the JVM looks at the object's runtime class to decide which implementation to call. The compiler only checks that the method exists on the declared type; the actual selection is deferred until the program runs.

This is what lets one loop handle a whole mix of types without ever asking what each one is:

import java.util.List;

class Shape {
    double area() { return 0; }
}

class Circle extends Shape {
    private final double r;
    Circle(double r) { this.r = r; }
    double area() { return Math.PI * r * r; }
}

class Square extends Shape {
    private final double side;
    Square(double side) { this.side = side; }
    double area() { return side * side; }
}

public class Main {
    public static void main(String[] args) {
        List<Shape> shapes = List.of(new Circle(1), new Square(2), new Circle(3));

        double total = 0;
        for (Shape shape : shapes) {
            total += shape.area();   // each call dispatches to the real subclass
        }
        System.out.printf("total area: %.2f%n", total);
    }
}

The loop only knows about Shape. Add a Triangle extends Shape later and this code keeps working unchanged - that is the whole point. Code depends on the abstraction, not the concrete list of types.

Upcasting and Downcasting

Storing a Dog in an Animal variable is upcasting - moving up the hierarchy to a more general type. It is always safe and Java does it implicitly, because every Dog is an Animal.

Going the other direction is downcasting - taking a parent reference and treating it as a specific subtype. This is a form of type casting between reference types, and it is only valid if the object really is that subtype, so you must write the cast explicitly, and you risk a ClassCastException if you are wrong:

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal { }

public class Main {
    public static void main(String[] args) {
        Animal a = new Dog();   // upcast - implicit, safe

        Dog d = (Dog) a;        // downcast - explicit, valid because a is really a Dog
        d.fetch();

        Animal c = new Cat();
        Dog wrong = (Dog) c;    // compiles, but throws ClassCastException at runtime
        wrong.fetch();
    }
}

The last cast compiles fine - the compiler can't prove it's wrong - but blows up when it runs because a Cat is not a Dog. Never downcast on faith.

Guard Downcasts with instanceof

Before downcasting, check the real type with instanceof. Modern Java lets you bind the result in the same expression (pattern matching for instanceof), so you skip the separate cast:

class Animal { }
class Dog extends Animal {
    void fetch() { System.out.println("fetching"); }
}
class Cat extends Animal {
    void scratch() { System.out.println("scratching"); }
}

public class Main {
    public static void main(String[] args) {
        Animal[] animals = { new Dog(), new Cat(), new Dog() };

        for (Animal animal : animals) {
            if (animal instanceof Dog dog) {     // checks type AND binds dog
                dog.fetch();
            } else if (animal instanceof Cat cat) {
                cat.scratch();
            }
        }
    }
}

instanceof returns false for null, so the check also protects you from a NullPointerException. That said, if you find yourself writing long instanceof chains, it is often a sign the behavior belongs inside the classes as an overridden method - let polymorphism do the branching for you.

Overriding vs Overloading

These two sound alike but are unrelated, and mixing them up is a classic source of confusion.

Overriding is a subclass replacing a parent method with the identical signature. It is resolved at runtime by the object's type - this is the polymorphism we have been using.

Overloading is one class having several methods of the same name but different parameter lists. It is resolved at compile time by the argument types, with no runtime dispatch involved:

public class Main {
    static String describe(int x)    { return "int: " + x; }
    static String describe(double x) { return "double: " + x; }
    static String describe(String x) { return "String: " + x; }

    public static void main(String[] args) {
        System.out.println(describe(5));      // int: 5
        System.out.println(describe(5.0));    // double: 5.0
        System.out.println(describe("five")); // String: five
    }
}

The compiler picks the matching describe purely from the argument's static type. There is no parent/child object involved, so this is not runtime polymorphism - it just reuses a method name.

A Common Gotcha: Fields Are Not Polymorphic

Only instance methods are dispatched at runtime. Fields and static methods are resolved by the declared type, which trips up a lot of people:

class Parent {
    String label = "parent";
    String name() { return "Parent"; }
}

class Child extends Parent {
    String label = "child";          // hides, does not override
    String name() { return "Child"; }
}

public class Main {
    public static void main(String[] args) {
        Parent p = new Child();
        System.out.println(p.label);    // parent  - field uses declared type
        System.out.println(p.name());   // Child   - method uses runtime type
    }
}

p.name() runs Child's version (polymorphism), but p.label reads Parent's field, because fields are hidden, not overridden. The fix is simple: keep fields private and access them only through methods, so the polymorphic call always wins.

Next: Access Modifiers

Polymorphism only works cleanly when subclasses can see and override the right members while the rest of your code can't reach in and break invariants. That balance is controlled by public, protected, private, and package-private access - the access modifiers, up next.