Composición construye comportamiento manteniendo otros objetos (una relación "has-a") y delegando hacia ellos. Herencia adquiere comportamiento extendiendo una clase ("is-a"). El consejo "favorecer composición" existe porque la herencia crea un acoplamiento fuerte y frágil a una clase base, mientras que la composición permanece 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
}
Al mantener una lista en lugar de ser una, Stack expone solo las operaciones que desea.
| Composición | Herencia |
|---|---|
| Flexible, intercambia partes en tiempo de ejecución | Fijo en tiempo de compilación |
| Oculta internos (delegación) | Hereda interfaz completa |
| Más cableado/boilerplate | Menos código cuando es verdaderamente is-a |
| Evita clase base frágil | Subclase se rompe si la clase base cambia |
Use herencia solo para relaciones is-a genuinas y estables; use composición para "Necesito este comportamiento".
La herencia expone la interfaz completa del padre, por lo que una subclase no puede controlar completamente su propio contrato — la fuga de Stack extends ArrayList es el ejemplo clásico.
La composición mantiene las relaciones explícitas e intercambiables, por lo que la inyección de dependencias, patrones de estrategia y la mayoría de diseños flexibles se basan en ella.