Komposition opbygger adfærd ved at holde andre objekter (et "has-a"-forhold) og delegere til dem. Arv erhverver adfærd ved at udvide en klasse ("is-a"). Rådet "foretrække komposition" eksisterer, fordi arv skaber tæt, skrøbelig kobbling til en basisklasse, mens komposition forbliver fleksibel.
<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
}
Ved at holde en liste i stedet for at være en eksponerer Stack kun de operationer, det ønsker.
| Komposition | Arv |
|---|---|
| Fleksibel, byt dele under køretid | Fastsat på kompileringstidspunktet |
| Skjuler internals (delegering) | Arver hele grænsefladen |
| Mere ledninger/boilerplate | Mindre kode, når det virkelig er is-a |
| Undgår skrøbelig basisklasse | Underklasse brydes, hvis basisklasse ændres |
Brug arv kun til ægte, stabile is-a-forhold; brug komposition til "Jeg har brug for denne adfærd".
Arv eksponerer hele forældre-grænsefladen, så en underklasse kan ikke fuldt kontrollere sin egen kontrakt — Stack extends ArrayList-lækagen er det klassiske eksempel.
Komposition holder forhold eksplicitte og udskiftelige, hvilket er grunden til, at afhængighedsindsprøjtning, strategimønstre og de fleste fleksible designs er afhængige af det.