Kompozycja buduje zachowanie poprzez posiadanie innych obiektów (relacja "has-a") i delegowanie do nich. Dziedziczenie uzyskuje zachowanie poprzez rozszerzenie klasy ("is-a"). Rada "faworyzuj kompozycję" istnieje, ponieważ dziedziczenie tworzy ciasne, kruche sprzężenie z klasą bazową, podczas gdy kompozycja pozostaje elastyczna.
<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
}
Przez posiadanie listy zamiast bycie jedną, Stack ujawnia tylko operacje, które chce.
| Kompozycja | Dziedziczenie |
|---|---|
| Elastyczna, zmień części w czasie wykonywania | Ustalona w czasie kompilacji |
| Ukrywa wewnętrzne elementy (delegacja) | Dziedziczy cały interfejs |
| Więcej przewodów/boilerplate | Mniej kodu, gdy naprawdę is-a |
| Unika kruche klasy bazowej | Subklasa pęka, jeśli baza się zmieni |
Używaj dziedziczenia tylko dla rzeczywistych, stabilnych relacji is-a; użyj kompozycji dla "Potrzebuję tego zachowania".
Dziedziczenie ujawnia cały interfejs rodzica, więc subklasa nie może w pełni kontrolować własnego kontraktu — wyciek Stack extends ArrayList to klasyczny przykład.
Kompozycja utrzymuje relacje jawne i wymienne, dlatego wstrzykiwanie zależności, wzorce strategii i większość elastycznych projektów na nich polegają.