Compositie bouwt gedrag door andere objecten te bezitten (een "has-a" relatie) en aan hen toe te vertrouwen. Overerving verwerft gedrag door een klasse uit te breiden ("is-a"). Het advies "verkies compositie" bestaat omdat overerving strakke, fragiele koppeling aan een basisklasse creëert, terwijl compositie flexibel blijft.
<T> <T> {
{ add(x); }
T { remove(size() - ); }
}
class Stack<T> {
private final List<T> items = new ArrayList<>(); // HAS-A list
void push(T x) { items.add(x); }
T pop() { return items.remove(items.size() - 1); }
// only push/pop are exposed → LIFO invariant is safe
}
Door een lijst te bezitten in plaats van te zijn, biedt Stack alleen de bewerkingen aan die het wil.
| Compositie | Overerving |
|---|---|
| Flexibel, onderdelen kunnen tijdens runtime worden verwisseld | Vast op compilatietijd |
| Verborgen internals (delegatie) | Neemt hele interface over |
| Meer bedrading/boilerplate | Minder code wanneer echt is-a |
| Vermijdt fragiele basisklasse | Subklasse breekt als basisklasse verandert |
Gebruik overerving alleen voor echte, stabiele is-a relaties; gebruik compositie voor "Ik heb dit gedrag nodig."
Overerving biedt de hele interface van de ouder aan, dus een subklasse kan zijn eigen contract niet volledig controleren — de Stack extends ArrayList lekkage is het klassieke voorbeeld.
Compositie houdt relaties expliciet en verwisselbaar, daarom leunen afhankelijkheidsinjectie, strategy patterns en meeste flexibele ontwerpen erop.