Composição constrói comportamento possuindo outros objetos (uma relação "tem-um") e delegando para eles. Herança adquire comportamento estendendo uma classe ("é-um"). O conselho "favoreça composição" existe porque herança cria acoplamento apertado e frágil a uma classe base, enquanto composição permanece flexível.
<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
}
Ao possuir uma lista em vez de ser uma, Stack expõe apenas as operações que deseja.
| Composição | Herança |
|---|---|
| Flexível, troque partes em tempo de execução | Fixo em tempo de compilação |
| Oculta internals (delegação) | Herda toda a interface |
| Mais fiação/boilerplate | Menos código quando realmente é-um |
| Evita classe base frágil | Subclasse quebra se a base muda |
Use herança apenas para relações genuínas e estáveis "é-um"; use composição para "Eu preciso deste comportamento".
Herança expõe toda a interface do pai, então uma subclasse não pode controlar completamente seu próprio contrato — o vazamento Stack extends ArrayList é o exemplo clássico.
Composição mantém relacionamentos explícitos e permutáveis, por isso injeção de dependência, padrões de estratégia e a maioria dos projetos flexíveis dependem dela.