Composition bygger beteende genom att hålla andra objekt (en "har-en"-relation) och delegera till dem. Arv förvärvar beteende genom att utöka en klass ("är-en"). Rådet "föredra composition" existerar eftersom arv skapar tätt, skört koppling till en basklass, medan composition förblir flexibel.
<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
}
Genom att hålla en lista istället för att vara en lista exponerar Stack bara de operationer den vill.
| Composition | Arv |
|---|---|
| Flexibel, byt delar under körtid | Fast vid kompilering |
| Döljer internals (delegering) | Ärver hela gränssnittet |
| Mer ledning/boilerplate | Mindre kod när det är verkligt är-en |
| Undviker spröd basklass | Subklass bryter om bas ändras |
Använd arv endast för äkta, stabila är-en relationer; använd composition för "jag behöver det här beteendet."
Arv exponerar förälderns hela gränssnitt, så en subklass kan inte helt kontrollera sitt eget kontrakt — Stack extends ArrayList läckan är det klassiska exemplet.
Composition håller relationer explicita och utbytbara, vilket är varför beroendeinjektion, strategi-mönster och mest flexibla konstruktioner förlitar sig på det.