At the end of the previous lesson something happened that we left unexplained. The method printCard(Material m) received a Book, a Magazine or a Dvd indistinctly, and each one responded according to what it really was: the book charged €0.25 per day, the DVD €0.50, the magazine €0.10. And all of that with a single line of calculation code, written only once in Material. That mechanism is called polymorphism —from the Greek for "many forms"— and it is the pillar that justifies the existence of inheritance. Without it, a class hierarchy would be little more than a way of saving lines; with it, it becomes the tool that lets you add new types without modifying existing code. This lesson explains how it works inside, how to use it well, and why ifs and switches on an object's type —the ones that filled your main in module 2— are a symptom of missing polymorphism.

1. Two different polymorphisms
2. Declared type versus actual type
3. Dynamic dispatch step by step
4. The central example: Material calculating fines
5. Upcasting: the implicit conversion
6. Downcasting and ClassCastException
7. instanceof and the Java 16 pattern
8. ifs on the type are a design smell
9. static members are not polymorphic: hiding
10. Fields and polymorphism: not those either
11. Polymorphism with arrays of the superclass
12. Common Mistakes and Tips
13. Exercises

Two forms of polymorphism coexist in Java and it is worth not confusing them:

You already master the first one: you studied it in 03-03 and there is no mystery to it, the compiler looks at the written types and picks. The second is the interesting one and the one that gives the OOP pillar its name; when somebody says "polymorphism" on its own, they almost always mean this one.

Every reference in Java has two types that may not coincide:

And from that come the two rules that govern everything else:

The declared type decides WHAT YOU CAN CALL. The actual type decides WHAT RUNS.

Check it:

The object is a DVD and it has its durationMinutes field, but the compiler only sees a Material and Material does not declare that field. The restriction is not arbitrary: the compiler must guarantee that the call is valid for any object that could be there, and that variable could hold a Book.

The mechanism by which the JVM picks the right implementation is called dynamic dispatch (or late binding). It works like this:

In two sentences: the compiler verifies that the method exists in the declared type, and the JVM searches for the implementation starting at the object's actual class and climbing the hierarchy until it finds it. That is why Book, which does not override getDailyRate(), ends up running Material's version.

This mechanism has a minimal performance cost (the JVM uses a method table and also optimises aggressively when hot), and in exchange it gives enormous flexibility. In module 10-07 you will see how the JIT compiler even removes that cost when it detects that in practice the same implementation always runs.

This is the example that sums up the whole module. Look at calculateFine, written only once in Material:

That method does not know —nor does it care— whether the object is a book, a magazine or a DVD. It calls getLoanDays() and getDailyRate(), and dynamic dispatch takes care of each material contributing its own numbers.

Output:

Verify it by hand: with 12 elapsed days, the book is still within term (15 days); the magazine is 5 days late (12 − 7) and pays 5 × 0.10 = €0.50, a minor delay because 5 ≤ 7; the DVD is 9 days late (12 − 3) and pays 9 × 0.50 = €4.50, severe because 9 > 7.

Three lines of business code and three different behaviours. And the most valuable property: if tomorrow Nexus Software adds technical maps or robotics kits, show will keep working untouched.

Assigning a subclass object to a superclass reference is called upcasting. It is implicit and always safe, because a Dvd is always a Material:

What changes and what does not with upcasting:

It is important to internalise that upcasting transforms nothing: it does not create a new object nor trim the original. It only changes the glasses the compiler looks at it with.

Downcasting is the inverse operation: treating a superclass reference as if it were the subclass. It requires explicit syntax, because it is not always safe:

If the actual object is not of that type, the program fails at run time:

The compiler accepts the conversion because it could be valid (a Material could be a Dvd), but the real check happens at run time. ClassCastException is studied as an exception in module 6; here it is enough to know that it exists and how to avoid it: by checking the type beforehand with instanceof.

The instanceof operator answers the question "is this object of this type?":

That pattern —check, cast, declare a variable— was so repetitive that Java 16 built it into the operator itself. It is instanceof with a type pattern:

The variable dvd only exists where the compiler can guarantee that the check was true, even in compound conditions:

Two useful details:

• null instanceof Anything returns false, it never throws an error. That makes instanceof an implicit null guard.
• instanceof is also true for superclasses: dvd instanceof Material is true.

Now the important part of the lesson. Compare these two ways of solving the same problem.

Without polymorphism, as you would have had to write it with what you knew in module 2:

With polymorphism:

The comparison, point by point:

The professional criterion, worth memorising:

If you write an if or a switch that asks what type an object is in order to decide what to do, a polymorphic method is almost always missing.

This does not mean instanceof is forbidden. There are legitimate uses:

• Implementing equals (lesson 03-09).
• Working with third-party APIs whose hierarchy you cannot modify.
• Retrieving a piece of data specific to a subtype in order to display it, such as a DVD's durationMinutes in a detailed card, when that data has no equivalent in the others.

The illegitimate case is the one that replaces behaviour that should live in the classes:

Here comes a trap you have to know about so as not to fall into it. static methods are not overridden: they are hidden, and they are resolved with the declared type, not the actual type.

The first line is the surprising one. The object is a Dvd, but since typeDescription() is static, the JVM does no dynamic dispatch: it uses m's declared type, which is Material. It is exactly the opposite of what instance methods do.

A direct contrast, in a table:

Acid test: if you add @Override to Dvd's static method, the compiler fails with "method does not override or implement a method from a supertype". One more reason to always write the annotation.

Practical tip: never call a static method through a reference (m.typeDescription()). Always write Material.typeDescription() or Dvd.typeDescription(), and the ambiguity disappears from the code.

The same rule applies to fields: fields are not polymorphic, they are resolved with the declared type.

The object contains both fields at once, and which one you see depends on the glasses you look at it with. It is such an absurd source of errors that the solution is simple: do not declare in a subclass a field with the same name as one in the superclass. And if what you want is a value that varies by type, use an overridable method, like getType() in BiblioTech.

Polymorphism shines when you handle many objects uniformly. For that you need to be able to store them together, and for the moment the only tool available is an array:

Provisional note. Arrays have a fixed size and are awkward for a real catalog: you cannot add or remove without creating another array. In module 5 ArrayList, HashMap and the rest of the collections framework will appear, which is the definitive solution. Use the array here as scaffolding to see polymorphism in action.

Output:

An array of Material can hold objects of any subclass, and the loop treats them all the same while each one does its own thing. This is, in essence, the reason OOP exists in large software.

One detail to bear in mind: when walking the array, m's declared type is Material, so you can only call what Material declares. If you need the books' author, you will need instanceof with a pattern:

And this is exactly one of the legitimate uses from section 8: extracting a piece of data that only exists in a subtype, not deciding business behaviour.

• Believing that upcasting "converts" the object. It does not touch it. It only limits what the compiler lets you call. The object is still what it was, and its overridden methods keep running.
• Downcasting without checking. (Dvd) m with no instanceof in front is a ClassCastException waiting to happen. Always use if (m instanceof Dvd dvd).
• Putting @Override on a static method. It does not compile, and that is its virtue: it warns you that you are not overriding, but hiding.
• Calling static methods through an instance. m.typeDescription() misleads about what is going to run. Use the class name.
• Redefining a field in the subclass. You end up with two fields of the same name in the same object and results that depend on the declared type. Do not do it.
• Chains of else if (x instanceof ...). They almost always mean a method is missing from the hierarchy. Before writing the third branch, ask yourself what method Material should have.
• Tip: when you add a subclass, try listing which methods it overrides. If it overrides none, perhaps you did not need a subclass but a field.
• Tip: program against the most general type that serves you. Declare Material m instead of Dvd d when you do not need what is specific to the DVD: your code will work in more cases. This principle is taken to the extreme in module 4 with interfaces.
• Tip: use your IDE's gutter marker. IntelliJ and Eclipse show an icon next to overridden methods and let you jump to the actual implementation with a click.

This exercise checks polymorphism's most valuable property. Nexus Software is adding robotics kits to the catalog: they are lent for 5 days, with a rate of €1.00/day (they are expensive), and they have a partCount field.

1. Create RoboticsKit as a subclass of Material.
2. Add it to the catalog array from section 11.
3. Run it without modifying a single line of Material, Book, Magazine, Dvd, show or the listing loop.
4. Manually verify the fine at 12 elapsed days and the severity.

Then answer: how many files did you have to touch? How many would you have touched with the switch from section 8?

A colleague has written this method in BiblioTechApp. Refactor it by removing the switch completely, moving each responsibility to the class it belongs to. State what new methods Material needs and which ones each subclass overrides.

Write a test class that demonstrates, in the same run, the three rules from sections 9 and 10:

1. An overridden instance method runs the actual type's version.
2. A redefined static method runs the declared type's version.
3. A redefined field is read according to the declared type, even though the object is the same.

In each case print the declared type, the actual type (with getClass().getSimpleName()) and the value obtained, and explain in writing why result 1 differs from results 2 and 3.

Solution 1

You only have to add it to the array:

Output (new row marked):

Manual verification, paying attention to the boundary: 12 − 5 = 7 days late; 7 × 1.00 = €7.00, below the €20 cap. And the severity is MINOR, not SEVERE, because the condition is late <= MINOR_THRESHOLD and MINOR_THRESHOLD is exactly 7. It is precisely the kind of boundary value lesson 02-05 taught you to check: thresholds are always tested with the three boundary values (6, 7 and 8), because a < instead of a <= would change this result without any other row of the table noticing.

Answer to the question. You have touched two files: a new one (RoboticsKit.java) and one line in BiblioTechApp to register it. With the switch from section 8 you would have had to locate and modify every method containing a switch on the type —fine calculation, listing, notices, validation—, with the risk of forgetting one and having the kit treated as a book without anyone noticing.

Solution 2

The switch decides two things —the notice channel and the warning days— which are properties of each format. Their home is the classes.

In Material, two new methods with the default value, and a third that composes the message only once:

In Magazine:

In Dvd:

Book overrides nothing: it inherits "email" and 3 days, which were precisely the original switch's default case. And BiblioTechApp loses the method:

Results:

Three concrete gains: the silent default disappears, each format gathers all its rules in its own file, and adding a new type no longer forces you to comb the code looking for forgotten switches.

Solution 3

Output:

Explanation. The line b == d gives true: there is a single object and two references, so any difference between the three outputs comes from the declared type, not from the object.

Case 1 uses dynamic dispatch: instance methods are resolved at run time by looking at the actual class, which is Derived in both cases. It is the only one of the three that is polymorphic.

Cases 2 and 3 are resolved at compile time. The compiler replaces b.staticMethod() with Base.staticMethod() and b.field with the field declared in Base, because that is the type the variable was declared with. The JVM never even gets to ask what object is behind it. That is why the same object exhibits two different values for field: the object contains both fields, and each reference reads its own.

The practical moral of the three cases together: polymorphism is exclusively a matter of instance methods. Any other mechanism —static, fields— is resolved by the written type and produces surprises if you try to use it as if it were polymorphic.

You have reached the core of object orientation. You tell the two polymorphisms apart —overloading, resolved by the compiler, and overriding, resolved by the JVM— and you understand the rule that governs them: the declared type decides what you can call, the actual type decides what runs. You have followed dynamic dispatch step by step and seen its practical consequence in the module's central example: a single calculateFine in Material that charges €0.25 to a book, €0.10 to a magazine and €0.50 to a DVD, without a single if on the type. You master implicit and safe upcasting, explicit and risky downcasting with its ClassCastException, and the modern way of protecting yourself with instanceof plus a type pattern (if (m instanceof Dvd dvd)), which checks, converts and declares in one line. You know how to recognise if/switch on the type as a design smell and to refactor them by moving each rule to the class it belongs to. And you know the two exceptions you must always keep in mind: static methods are not overridden, they are hidden, and fields are not polymorphic either; both are resolved by the declared type.

Above all, you have verified in practice the property that justifies the whole scaffolding: adding a robotics kit to the catalog cost one new class and one line, without touching anything that already worked.

One serious weakness remains in the current design, and you will have noticed it: every field is still public. Anyone can write book.available = true skipping lend()'s warnings, and nothing stops assigning a made-up fine to a loan. In the next lesson, Encapsulation, you will close that door: you will make the fields of Book, Employee and Loan private, you will learn the complete table of access modifiers, you will see why putting a setter on every field destroys precisely what you were trying to protect, and you will discover immutability and defensive copies as tools for making your objects' state genuinely their own.