Inheritance and Composition

Why this matters

• Inheritance is the most over-used feature in object-oriented code, and the resulting hierarchies are the hardest thing to refactor later.
• "Favour composition over inheritance" is advice everyone repeats and few can justify. The justification is specific and worth knowing.
• Java's single-inheritance rule forces a design decision early, so understanding the trade-off is not optional.

How inheritance works

public class Vehicle {
    protected final String registration;
    private int odometer;

    public Vehicle(String registration) {
        this.registration = registration;
    }

    public void drive(int kilometres) {
        odometer += kilometres;
    }

    public String describe() {
        return "Vehicle " + registration;
    }
}

public class Car extends Vehicle {
    private final int seats;

    public Car(String registration, int seats) {
        super(registration);              // must come first
        this.seats = seats;
    }

    @Override
    public String describe() {
        return super.describe() + " with " + seats + " seats";
    }
}

Single inheritance, and the reason for it

A Java class may extend exactly one class but implement any number of interfaces.

class Hybrid extends Car implements Electric, Serviceable { }   // legal
// class Broken extends Car, Truck { }                          // not legal

The reason is the diamond problem. If a class inherited concrete state and behaviour from two parents that both defined start(), there would be no principled way to decide which runs. Interfaces avoid this because, historically, they carried no implementation at all.

Composition

Composition means holding another object as a field and delegating to it.

public class Engine {
    void start() { }
    void stop() { }
}

public class Car {
    private final Engine engine = new Engine();     // has-a

    public void startUp() {
        engine.start();                              // delegation
    }
}

The difference from inheritance is that Car chooses exactly which parts of Engine to expose. It is not forced to inherit the whole surface.

Why composition usually wins

The deepest problem with inheritance is the fragile base class. A subclass can depend on how the parent is implemented, not just what it promises, and an innocent-looking change to the parent then breaks it.

// A counting set, by inheritance — and it is wrong
public class CountingSet<E> extends HashSet<E> {
    private int added;

    @Override
    public boolean add(E element) {
        added++;
        return super.add(element);
    }

    @Override
    public boolean addAll(Collection<? extends E> elements) {
        added += elements.size();
        return super.addAll(elements);     // which internally calls add() for each
    }

    public int added() { return added; }
}

CountingSet<String> set = new CountingSet<>();
set.addAll(List.of("a", "b", "c"));
System.out.println(set.added());      // 6, not 3

HashSet.addAll is implemented by calling add repeatedly. The subclass counted each element twice, once in its own addAll and once in its own add. Nothing in the documented contract told you that, and a future JDK could change it either way.

The composed version has no such problem:

public class CountingSet<E> {
    private final Set<E> delegate = new HashSet<>();
    private int added;

    public boolean add(E element) {
        added++;
        return delegate.add(element);
    }

    public boolean addAll(Collection<? extends E> elements) {
        added += elements.size();
        return delegate.addAll(elements);   // delegate's internals cannot call back in
    }

    public int added() { return added; }
}

When inheritance is the right answer

It is not always wrong. Reach for it when all of these hold.

this and super

Common misreadings

• "Inheritance means less code, so it is better." It means less typing now and more coupling forever. Count the cost on both sides.
• "protected fields are good for subclasses." They make the field part of your public contract for anyone who extends you. Prefer protected methods over protected fields.
• "Java has no multiple inheritance." It has no multiple inheritance of state. Multiple inheritance of type, and since Java 8 of default behaviour, both exist.
• "A subclass inherits private fields." The memory is there, but the names are not accessible. Only a parent method can reach them.
• "Deep hierarchies show good design." Depth beyond two or three levels is usually a sign that composition was the right tool.