Composition over Inheritance

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Composition

Building a class from other objects stored in its fields (a has-a relationship).

Delegation

Passing a call on to another object to do the work: engine.ignite() inside car.start().

has-a relationship

One object owns or uses another. A car has an engine. Modelled with a field, not extends.

Fragile base class problem

Changes inside a parent class silently break subclasses that depended on its internal behaviour.

Forwarding (wrapper) class

A class that implements an interface by passing every call to an inner object of that interface, adding behaviour where needed.

Strategy pattern

Putting a swappable algorithm behind an interface and holding it in a field so it can be changed.

Decorator pattern

Wrapping an object in another object with the same interface to add behaviour, like adding counting or logging.

Liskov Substitution Principle

A subtype must be usable anywhere its parent type is expected, without breaking correctness.

1. 1

   Add a logging decorator

   Write class LoggingFly implements FlyBehavior that holds another FlyBehavior and returns "(log) " + inner.fly(). Give the mallard new LoggingFly(new FlyWithWings()). You've just written a Decorator.

2. 2

   Fix the broken version two ways

   In the InstrumentedHashSet example, delete the addAll override. The count is now 3, but only because of HashSet's internal behaviour. Explain why this 'fix' is still fragile, then compare with the CountingSet version.

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

class InstrumentedHashSet<E> extends HashSet<E> {
    private int addCount = 0;
    @Override public boolean add(E e) { addCount++; return super.add(e); }
    @Override public boolean addAll(Collection<? extends E> c) { addCount += c.size(); return super.addAll(c); }
}

1. 1

   Composition = a class holds references to other objects in fields and calls them to do parts of its work (delegation). A Car has an Engine; car.start() calls engine.ignite(). The relationship is has-a, not is-a.

2. 2

   Why it's often better: inheritance exposes the parent's implementation, not just its interface. A subclass that overrides methods depends on *how* the parent calls its own methods internally. If that changes in the next version, the subclass breaks without any change of its own. This is the fragile base class problem, and the classic example (shown below) is a counting HashSet subclass that counts double.

3. 3

   Composition only depends on the other object's public contract. The wrapper decides exactly which methods to expose, can't be broken by the inner object's private call patterns, and can wrap any implementation of an interface, so one CountingSet works with HashSet, TreeSet or anything else.

4. 4

   Composition lets behaviour change at run time. A Duck that holds a FlyBehavior field can swap it for a RocketFly object later. A Duck subclass hierarchy can't change class after construction. This is the Strategy pattern, and wrapping an object to add behaviour while keeping its interface is the Decorator pattern.

5. 5

   The JDK has famous inheritance mistakes: Stack extends Vector (so a 'stack' lets you insert in the middle) and Properties extends Hashtable (so you can put non-String values that break getProperty). Prefer ArrayDeque for stacks.

6. 6

   Inheritance is still right when the subclass truly is a specialised version of the parent, both are under your control (same package or module), and the parent was designed and documented for extension. Liskov's rule must hold: a subclass object must work everywhere a parent object does.

• ↔

  Composition is more robust and flexible, but you write forwarding methods and the wrapper is a different type from the inner class unless both implement a shared interface.

• ↔

  Inheritance is shorter for true is-a relationships and gives polymorphism for free, but couples you to the parent's implementation and fixes behaviour at construction.

• ↔

  Decorators stack nicely, but deep stacks make debugging harder (many small objects, long stack traces). Keep wrapper chains short and name them clearly.

• Done when you can explain has-a vs is-a and pick one for a given design.

• Done when you can explain and reproduce the counting-HashSet fragile base class bug.

• Done when you can write a forwarding/decorator class around an interface.

• Done when you can implement Strategy with a swappable field.

• Done when you can name the JDK's Stack and Properties mistakes and the better alternatives.