Java inheritance and method overriding

Working model

Use inheritance when the subtype must satisfy the same contract. Extending a class just to reuse a helper couples unrelated behavior and can expose operations the subtype should not support.

Code

public class DeliveryCharge {
    public int chargePaise() {
        return 5000;
    }

    static class PickupCharge extends DeliveryCharge {
        @Override
        public int chargePaise() {
            return 0;
        }
    }

    public static void main(String[] args) {
        DeliveryCharge charge = new PickupCharge();
        System.out.println(charge.chargePaise());
    }
}

The output is 0. The reference type permits the call; the object’s runtime class supplies the overridden implementation. The annotation catches a mismatched signature at compilation.

Cost and design choices

Prefer composition when pricing policies should be replaceable independently of the object hierarchy. A contained policy object makes that dependency explicit.

Substitution has behavioral limits

A subclass inherits more than names: callers already have assumptions about the parent’s accepted inputs, results, and state changes. A child that unexpectedly rejects valid parent inputs or changes units breaks those assumptions even if the code compiles.

Prefer composition when the new type needs to use another object without promising that it can replace that object. Inherited mutable protected fields can make invariants harder to control because several layers can alter them.

Connected lessons

Continue with Java interfaces and replaceable behavior, Java Tutorial.

Common Mistakes

Overloading changes the parameter list and is a different operation from overriding. Static methods do not dispatch like overridden instance methods. A subclass must preserve expectations established by the parent contract.