Constructor Calls in Inheritance

The order is fixed by the language, not by your code. When you evaluate new ElectricCar, the runtime allocates the object, gives the instance fields their default values, runs the field initialisers and any initialiser blocks of the subclass, then runs the parent constructor, and finally runs the subclass constructor body.

public class Main {
    public static void main(String[] args) {
        new ElectricCar("model-3", 500);
    }
}

class Car {
    protected final String model;
    Car(String model) {
        this.model = model;
        System.out.println("car: " + model);
    }
}

class ElectricCar extends Car {
    private final int range;
    ElectricCar(String model, int range) {
        super(model);
        this.range = range;
        System.out.println("electric: " + model + " range " + range);
    }
}

The output makes the sequence visible. The car constructor runs first and prints its message, and only then does the electric car constructor run and print its own. The subclass body could not have run earlier, because it assigns to an inherited final field, and that field is only set by the parent constructor.

This is why the super call has to be the first statement of the constructor. The parent state must exist before the subclass can rely on it, and the language enforces the ordering rather than trusting you to remember it.

One more consequence worth mentioning: if a parent constructor calls an overridden method, the subclass version runs at that point, before the subclass's own fields are initialised. That is the classic surprise, and the usual workaround is to avoid calling overridable methods from constructors.

You have to say explicitly which parent constructor you want, because the compiler cannot assume a no-argument one exists. The child constructor starts with a super call naming the parent's constructor and the arguments it needs. If you leave it out, the code does not compile, with an error saying that the parent has no accessible constructor that takes no arguments.

The compiler error is a feature rather than an inconvenience. It means there is exactly one way to construct a subclass instance, and the parent is always fully initialised before the child begins. There is no path that skips the parent's setup.

The call has to be the first statement in the constructor, and you may make either a super call or a this call that delegates to another constructor of the same class, but not both in the same constructor. A chain of delegating constructors is fine as long as it terminates with a super call.

One design point to add for an interview: it is worth deciding deliberately whether your class hierarchy wants a no-argument constructor at all. If every subclass has to supply the same information to the parent, a single constructor taking that information keeps the hierarchy honest and avoids repeating the super call in every child.