Composition costruisce il comportamento contenendo altri oggetti (relazione "has-a") e delegando a loro. Inheritance acquisisce il comportamento estendendo una classe ("is-a"). Il consiglio "favorire la composizione" esiste perché l'ereditarietà crea un accoppiamento stretto e fragile alla classe base, mentre la composizione rimane flessibile.
<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
}
Tenendo una lista invece di esserne una, Stack espone solo le operazioni che vuole.
| Composizione | Ereditarietà |
|---|---|
| Flessibile, scambia le parti a runtime | Fissato al compile time |
| Nasconde gli interni (delegazione) | Eredita l'intera interfaccia |
| Più cablaggio/boilerplate | Meno codice quando veramente is-a |
| Evita fragile base class | La sottoclasse si rompe se la base cambia |
Usa l'ereditarietà solo per relazioni is-a genuine e stabili; usa la composizione per "ho bisogno di questo comportamento".
L'ereditarietà espone l'intera interfaccia della classe genitore, quindi una sottoclasse non può controllare completamente il suo contratto — la perdita Stack extends ArrayList è l'esempio classico.
La composizione mantiene le relazioni esplicite e intercambiabili, ecco perché l'iniezione delle dipendenze, i pattern strategici e la maggior parte dei design flessibili si basano su di essa.