Polymorphism

You can now build a class on top of another and replace a method the parent gave you. Here is the idea that makes all of that pay off: you can write one piece of code that talks to the general kind of thing, and at runtime each specific thing does its own version of the work. One word in your code, many behaviors when it runs. That is polymorphism, and it is the quiet engine under most real Java programs.

A word that means “many shapes”#

Polymorphismcomes from Greek: “poly” means many, “morph” means form or shape. In Java it means one thing in your code, the general type, can take many forms when the program actually runs. You will see exactly what that buys you in a moment. It is easiest to see with a concrete problem.

Suppose we are modelling a small zoo. We already wrote an Animal class, and from it we built Dog and Cat, each overriding speak() to make its own noise. Now the keeper wants every animal in the zoo to speak, one after another. With what you know so far, you might keep each animal in its own variable and call each one by hand.

That works for two animals. But a zoo has hundreds, and they come and go. Writing one named variable and one hand-written call per animal does not scale, the same ache you felt when one customer became many in the first OOP lesson. What we want is to put all the animals in an array and walk it with a loop. But an array holds one type. Can a single array hold a Dog and a Cat at the same time?

One array, many kinds of object#

It can, and this is the heart of the lesson. Because a Dog is-a Animal and a Cat is-a Animal, an Animal[]array can hold either of them. The array's declared element type is Animal, the general type, and any object that is-a Animal is welcome in it. Now watch what one loop does.

Step through it and watch the one line that matters: zoo[i].speak(). It is the same line every time around the loop. The code never mentions Dog or Cat. Yet the output is Woof, then Meow, then Some animal sound. Each object did its own version of speak(). The loop asked “animal, speak” and each animal answered in its own voice.

Key idea

One line of code, zoo[i].speak(), produced three different behaviors. The code is written against the general type Animal, and the specific object decides what actually happens. That is polymorphism in one sentence.

Upcasting: a Dog standing in an Animal-shaped slot#

Slow the array down to a single variable and the mechanism is easier to see. Look closely at this line: Animal a = new Dog();. The left side says the variable a has type Animal. The right side builds an actual Dog. So the variable's declared type and the object's real type are different. Storing a Dog in an Animal variable like this is called upcasting: you are looking at a specific thing through the lens of its more general type.

Here is the part that surprises people. The variable a is typed Animal, so you might expect a.speak() to run Animal's version and print Some animal sound. It does not. It prints Woof. The object inside a is a real Dog, and the Dog's overridden speak() is the one that runs. The type on the variable did not change what the object is.

Read the middle row twice, because it is the whole trick. The declared type controls what is allowed. The real object controls what happens. Upcasting is always safe and automatic: every Dog truly is an Animal, so no information is lost and Java never complains. You are just choosing to forget the extra Dog details for a while.

The name for “the right version runs”

That behavior, where the object's own overridden method is the one that runs even though the variable is a more general type, is called dynamic dispatch (also called late binding or runtime polymorphism). Dispatchjust means “deciding which method to call”. It is dynamic because the decision is made while the program runs, based on the real object, not while it is being compiled. You met this idea in method overriding; here is the why behind it.

That upward search decides what happens when a class does not override a method at all. Below, Cat and Puppy are both empty: neither overrides speak(). Puppy extends Dog, and Cat extends Animal directly.

It prints Woof, Some animal sound, Woof. For the cat, the search starts in Cat, finds no speak(), and moves up to Animal. For the puppy, it starts in Puppy, finds nothing, and moves up one class to Dog, which has a speak(), so the search stops there. A puppy barks because its nearest ancestor with a speak() is Dog.

Adding a new kind without touching the loop#

It is fair to ask what all this buys you beyond a tidy loop. The payoff is that your code stops caring about the specific kinds. Go back to the zoo loop. It says zoo[i].speak() and nothing more. Now suppose the zoo gets a Cow. You write a new Cow class that extends Animal and overrides speak(), drop a new Cow() into the array, and the loop prints Moo in the right place. You did not touch the loop. You did not touch Dog or Cat. The general code kept working because it only ever spoke to the general type.

Key idea

Code written against the general type does not need to change when you add new specific types. You extend the program by adding classes, not by editing the code that uses them.

This is the difference between a program that fights you as it grows and one that welcomes new cases. A loop with a long chain of ifchecks, “if it is a dog do this, else if it is a cat do that”, has to be hunted down and edited every single time a new animal appears, and it is easy to miss one. Polymorphism deletes that chain. Each class already knows how to behave; the loop just asks.

1public class Main {
2    public static void main(String[] args) {
3        Ticket[] order = { new Ticket(), new ChildTicket(), new VipTicket() };
4 
5        double total = 0;
6        for (int i = 0; i < order.length; i++) {
7            System.out.println(order[i].name() + ": " + order[i].price());
8            total = total + order[i].price();
9        }
10        System.out.println("Total: " + total);
11    }
12}
13 
14class Ticket {
15    String name() {
16        return "Adult";
17    }
18 
19    double price() {
20        return 12.0;
21    }
22}
23 
24class ChildTicket extends Ticket {
25    // TODO: a child ticket is called "Child" and costs 6.0
26}
27 
28class VipTicket extends Ticket {
29    // TODO: a VIP ticket is called "VIP" and costs 30.0
30}

Asking an object what it really is#

Treating everything as an Animal is exactly what we wanted for speak(). But sometimes a specific kind can do something the general type cannot. A Dog might be able to fetch(), an action no plain Animal has. If your variable is typed Animal, the compiler will not let you call a.fetch(), because not every animal can fetch. The declared type only allows what is guaranteed for all animals.

So first you need a way to ask, at runtime, “is this particular object actually a Dog?” The operator instanceof answers exactly that. The expression a instanceof Dog evaluates to a boolean: true if the real object is a Dog or a subclass of Dog, and false otherwise. It is also false when a holds null, so the check itself never crashes.

The answer is true, true, false. The object is a Dog, so the first check passes. A Dog is also an Animal, so the second passes too: instanceofasks “is it this type, or some kind of this type?”. The object is not a Cat, so the last one is false. To get the name of the real class, for example in a debugging message, call a.getClass().getSimpleName(), which returns the String "Dog".

Downcasting: reaching the specific again#

Once instanceof has confirmed the object really is a Dog, you can convert the Animal view back into a Dog view so the compiler lets you call fetch(). That conversion is written (Dog) a and is called downcasting: moving from the general type back down to the specific one. The cast does not change the object at all (it was always a Dog); it only changes the type you are looking at it through. Here is the full pattern, the one you will reach for again and again.

Trace it and the shape becomes clear. a holds a Dog, so a.speak() prints Woof by dynamic dispatch. Then a instanceof Dog is true, so we step inside the if, downcast with (Dog) a into d, and now d.fetch() is allowed and prints Fetching the ball. For c, which holds a Cat, c instanceof Dog is false, so we take the else branch and print c is not a Dog. The check protected us from doing something a cat cannot do.

1public class Main {
2    public static void main(String[] args) {
3        Animal[] pets = { new Dog(), new Cat(), new Dog() };
4        int fetches = 0;
5 
6        for (int i = 0; i < pets.length; i++) {
7            pets[i].speak();
8            Dog d = (Dog) pets[i];   // TODO: crashes on the cat
9            d.fetch();
10            fetches++;
11        }
12        System.out.println(fetches + " fetches");
13    }
14}
15 
16class Animal {
17    void speak() {
18        System.out.println("Some animal sound");
19    }
20}
21 
22class Dog extends Animal {
23    @Override
24    void speak() {
25        System.out.println("Woof");
26    }
27 
28    void fetch() {
29        System.out.println("Fetching the ball");
30    }
31}
32 
33class Cat extends Animal {
34    @Override
35    void speak() {
36        System.out.println("Meow");
37    }
38}

Further reading#

• Polymorphism, the dev.java tutorial, which calls this behavior virtual method invocation
• The instanceof operator, section 15.20.2 of the Java Language Specification
• ClassCastException in the Java SE 25 API documentation