Polymorphism pitfalls & constructors

The order of construction under inheritance

When you create a subclass object, Java builds it base-first. The exact order is:

1. The superclass constructor runs (recursively, up to Object first).
2. The subclass's instance field initializers run, in source order.
3. The rest of the subclass constructor body runs.

This base-first rule sets up the famous trap.

Worked example: a constructor that calls an overridable method

class Glyph {
    Glyph() { draw(); }                  // calls an overridable method!
    void draw() { System.out.println("Glyph.draw"); }
}

class RoundGlyph extends Glyph {
    private int radius = 5;              // field initializer
    @Override void draw() {
        System.out.println("RoundGlyph.draw, radius = " + radius);
    }
}

Now new RoundGlyph(); prints:

RoundGlyph.draw, radius = 0

Why 0, not 5? Trace it:

1. RoundGlyph's construction begins; the implicit super() runs Glyph() first.
2. Inside Glyph(), draw() is called. Because draw() is overridden and dispatch is dynamic, it runs RoundGlyph.draw() — the subclass version — even though we are still inside the superclass constructor.
3. But RoundGlyph's field initializer (radius = 5) has not run yet — it runs after super() returns. So radius still holds its default value, 0.

The overridden method runs against a half-built object. The lesson: never call an overridable (non-final, non-private, non-static) method from a constructor. Either make such helper methods final/private, or don't call them during construction.

What is NOT polymorphic

Late binding applies only to overridable instance methods. Three things resolve by the static (declared) type instead, and the exam loves to test this:

• Fields are not polymorphic. A field reference is resolved by the declared type. If both Super and Sub declare a field x, then Super ref = new Sub(); ref.x reads Super's x (the field is hidden, not overridden).
• static methods are not polymorphic. They are hidden, not overridden, and bound to the declared type.
• private methods are not overridable at all. A subclass method with the same name is a new, independent method; the superclass's own code keeps calling the superclass's private version.