Composition construit le comportement en tenant d'autres objets (une relation « has-a ») et en déléguant à ces derniers. Héritage acquiert le comportement en étendant une classe (« is-a »). Le conseil « privilégier la composition » existe parce que l'héritage crée un couplage étroit et fragile à une classe de base, tandis que la composition reste flexible.
<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
}
En tenant une liste au lieu d'en être une, Stack expose uniquement les opérations qu'elle souhaite.
| Composition | Héritage |
|---|---|
| Flexible, peut changer les composants à l'exécution | Fixé à la compilation |
| Cache les détails internes (délégation) | Hérite de toute l'interface |
| Plus de câblage/boilerplate | Moins de code quand vraiment is-a |
| Évite la classe de base fragile | Sous-classe casse si la base change |
Utilisez l'héritage seulement pour les relations is-a authentiques et stables ; utilisez la composition pour « j'ai besoin de ce comportement ».
L'héritage expose l'interface complète du parent, donc une sous-classe ne peut pas contrôler pleinement son propre contrat — la fuite Stack extends ArrayList en est l'exemple classique.
La composition maintient les relations explicites et échangeables, ce qui explique pourquoi l'injection de dépendances, les patterns strategy et les designs les plus flexibles s'y appuient.