La composición vs la herencia es uno de los debates más persistentes en diseño de software orientado a objetos. La guía clásica de Gang of Four lo resume en una frase: favorecer la composición sobre la herencia. Pero ¿por qué? ¿Y cuándo la herencia es legítimamente la mejor opción? Entender esta distinción mejora directamente la calidad de la arquitectura de cualquier proyecto de software.
Herencia: el poder y la trampa
La herencia permite que una clase hija reutilice el comportamiento de una clase padre. Es seductoramente simple: si Animal tiene el método moverse(), Perro hereda ese método sin reimplementarlo. El ahorro de código es real, la jerarquía es clara y el modelo mental es intuitivo.
El problema aparece cuando la jerarquía crece o los requisitos cambian. La herencia crea acoplamiento fuerte: cambiar la clase padre puede romper todas las clases hijas. La herencia múltiple introduce el problema del diamante donde el orden de resolución de métodos se vuelve ambiguo.
Composición: flexibilidad a costo de más código
La composición construye comportamiento combinando objetos que implementan interfaces específicas. En lugar de que Perro herede de Animal, Perro tiene un componente Movimiento y un componente Sonido. Este diseño permite cambiar el comportamiento de movimiento sin afectar el sonido.
- Bajo acoplamiento: Los componentes son independientes entre sí.
- Fácil de testear: Cada componente puede testearse de forma aislada.
- Flexible en runtime: Los componentes pueden cambiarse dinámicamente.
- Evita jerarquías profundas: No hay herencia de 5 niveles que nadie entiende.
En PHP y WordPress: ejemplos concretos
WordPress usa herencia en pocas partes (WP_Query, WP_HTTP), pero el ecosistema de plugins abusa de ella frecuentemente. La alternativa compositiva en WordPress es usar hooks y filtros, exactamente como WordPress fue diseñado para ser extendido. Los hooks son composición pura: el plugin agrega comportamiento sin heredar de ninguna clase de WordPress.
Cuándo la herencia SÍ tiene sentido
Si podés explicar la relación con tiene un, usá composición. Si solo funciona con es un, considerá herencia.
La herencia es correcta cuando existe una relación es un real y estable: un AdminUser es un User con atributos adicionales. También aplica para el Template Method pattern, donde la clase base define el esqueleto de un algoritmo y las subclases implementan los pasos específicos.
En Octopus Agencia Digital escribimos código WordPress con arquitectura limpia y mantenible. Si querés revisar la arquitectura de un plugin o proyecto, hablá con nuestro equipo técnico.
