Composition over inheritance

Written Explanation

Composition: has-a in code

Composition means a class has a field whose type is another class, and its methods use that object to do part of the work.

class Engine {
    void ignite() {
        System.out.println("Engine running");
    }
}

class Car {
    private final Engine engine;     // has-a

    Car(Engine engine) {
        this.engine = engine;
    }

    void start() {
        engine.ignite();             // forward the work
    }
}

new Car(new Engine()).start() prints Engine running.

Calling a method on the held object from your own method is called forwarding or delegation. The Car decides which of the engine's abilities to offer, under which names. A caller of Car sees start(), not ignite().

The two tests

Say both sentences and see which one is true:

• A SavingsAccount is an Account: inherit.
• A Car has an Engine: compose.
• A Library has Books: compose.
• An Order has a Customer: compose.

The test is necessary but not enough. Even when the sentence "X is a Y" is true in English, it must also be true in code: every promise the parent makes must hold for the child. The next section shows a famous case where it is not.

Why "is-a" in maths is not always extends

In geometry a square is a rectangle. In code, give Rectangle independent setWidth and setHeight, and make Square extend it. A square must keep both sides equal, so it overrides both setters to change both sides:

class Rectangle {
    protected int width;
    protected int height;

    void setWidth(int w) { width = w; }
    void setHeight(int h) { height = h; }
    int area() { return width * height; }
}

class Square extends Rectangle {
    @Override
    void setWidth(int w) { width = w; height = w; }

    @Override
    void setHeight(int h) { width = h; height = h; }
}

Code written for rectangles expects that setting the width to 5 and the height to 2 gives an area of 10:

static void stretch(Rectangle r) {
    r.setWidth(5);
    r.setHeight(2);
    System.out.println("expected 10, got " + r.area());
}

(Passing a Square where a Rectangle is expected is allowed because of the is-a relationship; the next module explains it fully.) The output:

expected 10, got 10
expected 10, got 4

A Square does not behave as a Rectangle does, so the promise of inheritance is broken. The honest design is two separate classes, or a Square that has a side and offers area() on its own. "Is-a" in everyday language is a clue. The real test is: can a child be used everywhere the parent is, with no surprises?

Signs that inheritance is the wrong tool

• The child would inherit methods it should not offer. If a Stack extends a list class, callers can insert in the middle of the stack. (Lesson 7 refactors exactly this.)
• The reason for extends is "I want that code" and the is-a sentence sounds forced.
• The child needs only a few of the parent's methods.
• The hierarchy keeps growing: a fourth or fifth level of children, so that a change at the top ripples through everything.
• The parent is a class you do not control and was not designed for extension.
• You want to change behavior at runtime: a class's parent is fixed when you write it.

Why composition is more flexible

1. Narrow surface. The holder chooses which methods to expose. Nobody can call something you did not forward.
2. Looser coupling. A child sees the parent's protected parts and depends on how the parent works inside. A holder only depends on the held object's public methods. The parent author can change the inside of a base class and silently break a child; with composition a change to the inside of the held class is usually harmless.
3. Swappable parts. The held object is chosen when you construct the holder (or later, if you provide a way). Two Logger objects can hold different Sinks, as in Example 3. A superclass cannot be replaced after the class is written.
4. No single-parent limit. A class can hold any number of objects, but can extend only one class.

The cost: forwarding code

Composition has a price: you write the forwarding methods yourself, one per capability you want to expose, while inheritance gives them for free. This is the reason beginners overuse extends. Remember that typing a few lines of forwarding is cheap compared to untangling a wrong hierarchy later. The common advice, often summarized as "favor composition over inheritance" and described in the Wikipedia article on the principle, is a guideline to apply selectively, not an absolute ban. Inheritance stays right for a real is-a relationship in a hierarchy designed for it, like SavingsAccount and Account.