Aprende cuándo heredar y cuándo componer objetos para reducir acoplamiento, evitar jerarquías frágiles y mantener flexibilidad en sistemas reales.
La herencia expresa relación `es-un` (`Admin` es un `Usuario`), mientras composición expresa `tiene-un` (`Pedido` tiene un `CalculadorImpuestos`).
Usar herencia por comodidad suele crear jerarquías rígidas y difíciles de cambiar.
La composición permite reemplazar comportamientos sin tocar la clase principal.
En Python profesional, la regla práctica frecuente es: prefiere composición salvo que la herencia sea semánticamente clara.
Úsala cuando exista una relación de tipo real y estable.
Si una subclase rompe reglas de la clase base o ignora parte de su contrato, la jerarquía está mal diseñada.
La herencia puede ser útil para compartir comportamiento común en un dominio bien definido.
Evita cadenas profundas de herencia; complican lectura y depuración.
Una clase delega responsabilidades en otras piezas especializadas.
Con composición puedes cambiar una dependencia por otra implementación sin reescribir todo el objeto principal.
Este patrón favorece testeo: puedes inyectar dobles de prueba (mocks/fakes) fácilmente.
También ayuda a mantener clases pequeñas y cohesionadas.
Elige patrón según estabilidad semántica y necesidad de variación.
Muchos problemas de mantenimiento vienen de herencias prematuras que parecían elegantes al principio.
Componer objetos con dependencias explícitas hace más fácil evolucionar arquitectura sin romper contratos previos.
Tu objetivo no es usar un patrón "bonito", sino reducir coste de cambio futuro.
Aprende cuándo heredar y cuándo componer objetos para reducir acoplamiento, evitar jerarquías frágiles y mantener flexibilidad en sistemas reales.
Código del tema: class Usuario: pass
Úsala cuando exista una relación de tipo real y estable.
Si una subclase rompe reglas de la clase base o ignora parte de su contrato, la jerarquía está mal diseñada.
La herencia puede ser útil para compartir comportamiento común en un dominio bien definido.
Evita cadenas profundas de herencia; complican lectura y depuración.
Una clase delega responsabilidades en otras piezas especializadas.
Con composición puedes cambiar una dependencia por otra implementación sin reescribir todo el objeto principal.
Este patrón favorece testeo: puedes inyectar dobles de prueba (mocks/fakes) fácilmente.
También ayuda a mantener clases pequeñas y cohesionadas.
La lógica de arranque vive en `Motor`.
`Coche` delega en `Motor`.
Elige patrón según estabilidad semántica y necesidad de variación.
Muchos problemas de mantenimiento vienen de herencias prematuras que parecían elegantes al principio.
Componer objetos con dependencias explícitas hace más fácil evolucionar arquitectura sin romper contratos previos.
Tu objetivo no es usar un patrón "bonito", sino reducir coste de cambio futuro.