Komposisjon bygger oppførsel ved å holde andre objekter (et "has-a" forhold) og delegere til dem. Arv tilegner oppførsel ved å utvide en klasse ("is-a"). Rådet "foretrekk komposisjon" eksisterer fordi arv skaper tett, skjør sammenkobling til en basisklasse, mens komposisjon forblir 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 å holde en liste i stedet for å være en, avslører Stack bare operasjonene det ønsker.
| Komposisjon | Arv |
|---|---|
| Fleksibel, bytt deler ved kjøretid | Fast på kompileringstid |
| Skjuler internals (delegering) | Arver hele grensesnittet |
| Mer ledninger/boilerplate | Mindre kode når virkelig is-a |
| Unngår skjør basisklasse | Subklasse brytes hvis basisklasse endres |
Bruk arv bare for genuine, stabile is-a forhold; bruk komposisjon for "Jeg trenger denne oppførselen."
Arv avslører forelderens hele grensesnitt, så en subklasse kan ikke fullt kontrollere sin egen kontrakt — Stack extends ArrayList lekkasjen er det klassiske eksemplet.
Komposisjon holder forhold eksplisitte og utbyttbare, det er grunnen til at avhengighetsinject, strategimønstre og de fleste fleksible design stoler på det.