Komposition erstellt Verhalten durch Halten anderer Objekte (eine "has-a"-Beziehung) und Delegieren an sie. Vererbung erwirbt Verhalten durch Erweitern einer Klasse ("is-a"). Der Rat "Komposition bevorzugen" existiert, weil Vererbung enge, zerbrechliche Kopplung zu einer Basisklasse erzeugt, während Komposition flexibel bleibt.
<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
}
Durch Halten einer Liste statt Sein einer Liste stellt Stack nur die Operationen bereit, die es möchte.
| Komposition | Vererbung |
|---|---|
| Flexibel, Teile zur Laufzeit austauschen | Zur Compile-Zeit fixiert |
| Verbirgt Internals (Delegierung) | Erbt gesamte Schnittstelle |
| Mehr Verdrahtung/Boilerplate | Weniger Code, wenn wirklich is-a |
| Vermeidet fragile Basisklasse | Subklasse bricht, wenn sich Basisklasse ändert |
Verwenden Sie Vererbung nur für echte, stabile is-a-Beziehungen; verwenden Sie Komposition für "Ich brauche dieses Verhalten".
Vererbung legt die gesamte Schnittstelle des Parents offen, daher kann eine Subklasse ihren eigenen Vertrag nicht vollständig kontrollieren — das Stack extends ArrayList-Leck ist das klassische Beispiel.
Komposition hält Beziehungen explizit und austauschbar, weshalb Dependency Injection, Strategy Patterns und die meisten flexiblen Designs sich darauf verlassen.