Estás frente al marcador del pizarrón, con el corazón desbocado. El entrevistador suelta una sonrisita: «Diferencia agregación de composición, con ejemplo del mundo real, ya».
¿Pánico? Olvídalo.
Las relaciones OOP —asociación, agregación, composición, herencia— sostienen el 70% de los codebases empresariales que aún rugen por ahí, según encuestas recientes de Stack Overflow. El drama: los devs se aprenden definiciones de memoria y luego les da un cortocircuito bajo presión. El mercado no perdona. Con contrataciones backend por las nubes un 15% (datos LinkedIn, Q3 2024), tener esto claro te abre puertas. No es humo. Es tu arma secreta.
Y el post original lo clava con mnemotécnicas tan pegajosas que sobreviven a tu bajón de cafeína.
Dos objetos están relacionados, pero pueden existir por separado. Ejemplo: Un profesor y un alumno. El profesor enseña a los alumnos. Ambos existen sin necesidad del otro. Truco de memoria: Gente en el mismo grupo de WhatsApp.
En el clavo. La asociación es el lazo más flojo —piensa en uses. El profesor usa datos de alumnos, pero borra uno y el otro ni se entera. Ciclos de vida independientes.
¿Por qué las relaciones OOP siguen reinando en entrevistas en 2024?
Las entrevistas miden claridad, no papagayo. Gigantes como Google o Meta te machacan con esto porque relaciones flojas generan bugs —eliminaciones en cascada mal hechas, fugas de memoria por herencias exageradas. Los datos lo confirman: el 40% de incidentes en producción vienen de modelado de objetos pobre (informe State of DevOps de O’Reilly).
Pero mira el panorama completo. La programación funcional sube como espuma —tiendas de Elixir o Rust se duplican cada año. Aun así, OOP no se va. ¿Por qué? Legado. Bancos, aseguradoras: billones en monolitos Java/C#. Dominar esto no es opcional; es tu seguro de sueldo.
Mi veredicto: estas mnemotécnicas destrozan tutoriales inflados de hype. Bootcamps corporativos te marean con diagramas; esto va al grano. Apuesto fuerte: con microservicios fragmentando codebases, agregación y composición subirán un 25% para 2026 —composabilidad sin las guerras de herencia de los ‘90 en Smalltalk. La historia se repite.
Siguiente: agregación. Has-a débil.
Un objeto contiene a otro, pero sobreviven por separado. Ejemplo: Un equipo tiene jugadores. Si borras el equipo, los jugadores siguen vivos. Truco de memoria: Una empresa contrata empleados (pueden renunciar).
Perfecto. El equipo guarda referencias a jugadores —borra el equipo, jugadores intactos (quizá fichan por rivales). En UML, diamante con flecha vacía. En código? List<Player> jugadores; sin cascada en el destructor. Caos real: carritos de e-commerce. Borra el carrito? Los items no desaparecen —son stock del catálogo.
Pausa un segundo. Los empleados renuncian a diario; las empresas quiebran menos. La independencia manda.
Composición lo da vuelta —has-a fuerte. El padre manda sobre el hijo por completo.
Un objeto posee totalmente a otro. Si el padre muere, el hijo muere. Ejemplo: Una casa tiene habitaciones. Destruye la casa → las habitaciones se van. Truco de memoria: Cuerpo humano → órganos.
¡Pum! Casa eliminada? Habitaciones al garete. Ciclos de vida soldados. En código: habitaciones instanciadas dentro del constructor de la casa, sin refs externas. Imán de bugs si lo haces mal —habitaciones zombis acechando el garbage collector.
Herencia: is-a.
Una clase hereda propiedades/comportamiento de otra. Ejemplo: Un perro es un animal. El perro coge todos los rasgos comunes de animal. Truco de memoria: Hijo hereda rasgos de padres.
Clásico. Perro extiende Animal, se lleva bark(), eat(). Pero ojo —el problema del diamante mató diseños tempranos. Veredicto moderno? Prefiere composición sobre herencia (principio GoF). La FP le está dando una lección a OOP.
Asociación vs agregación: ¿Cuándo la cagan los devs?
Prueba rápida, sacada tal cual: ¿El hijo sobrevive sin padre? Sí → agregación. No → composición.
