Inheritance Questions Explained

Inheritance is a way for one type to acquire the state and behaviour of another and then specialise it. The child class is said to be a subclass of the parent, and it may add new members or override inherited ones. Java supports single class inheritance and multiple interface implementation, and it enforces that a subclass is substitutable for its parent at the type level.

public class Main {
    public static void main(String[] args) {
        Notification email = new EmailNotification("order shipped");
        Notification sms = new SmsNotification("order shipped");
        email.send();
        sms.send();
    }
}

abstract class Notification {
    protected final String body;
    Notification(String body) { this.body = body; }
    abstract void send();
    void log() { System.out.println("queued: " + body); }
}

class EmailNotification extends Notification {
    EmailNotification(String body) { super(body); }
    void send() { System.out.println("email -> " + body); }
}

class SmsNotification extends Notification {
    SmsNotification(String body) { super(body); }
    void send() { System.out.println("sms -> " + body); }
}

Extending makes sense when the relationship really is a kind-of relationship and the shared behaviour is genuinely the same. Here every notification carries a body and knows how to send itself; what differs is only the delivery channel. The abstract send method makes the variation explicit, and the base class holds everything the subclasses share.

Composition is often the better tool. If you only need to reuse the logic rather than express a type relationship, hold the other object as a field and delegate to it. That keeps the classes independent, avoids a fragile base class, and lets you change the strategy at runtime rather than locking it in at compile time.

The rule of thumb to state out loud: extend when you can say the child is a parent without flinching, and compose when you can only say the child uses a parent.

Apply the substitutability test. Ask whether the child could be handed to any code that currently accepts the parent, and whether that code would still behave correctly. If the answer is no, you do not have an inheritance relationship, you have a code-sharing shortcut wearing a costume.

There is a sharper test involving behaviour. Inheritance says the child may only narrow or add behaviour, never contradict it. A Square that cannot be used wherever a Rectangle is expected, or a ReadOnlyCollection that throws on every read, breaks the promise. The classic failure is the classic example: a Square is-a Rectangle geometrically, but a Rectangle can be resized after creation and a Square cannot, so the subclass cannot honour the parent's contract.

Watch for the tells. If the child needs the parent to have protected state it constantly overrides, if the parent carries fields only some children use, or if you find yourself overriding a method just to throw an exception, the hierarchy is wrong.

There is also the inheritance-versus-composition escape hatch. When the relationship is only about reusing code, put the reusable behaviour in a collaborating object and hold it as a field. The type relationship disappears, but the reuse survives, and you are no longer forced to inherit in order to avoid duplication. Many strong answers end with that recommendation, because it converts an unanswerable design debate into a mechanical decision.