Programación Orientada a Objetos:
Asociación vs Composición
Por Darel el 14 de Julio de 2010 con 47,275 visitas
Tecnologia y otros Otros tutoriales por Darel.
En lo personal, conceptos que me parecieron bastante difíciles de comprender cada vez que trataba de estudiar Programación Orientada a Objetos. Por eso trataré de crear una explicación sencilla para los que ahora se ven en mi situación. Porque el que domines un lenguaje de programación no te garantiza que harás un buen diseño del sistema.
Los dos conceptos que debes conocer cómo mínimo cuando intentas descifrar la forma en que tus objetos deben interactuar son Asociación yComposición.
Asociación
La asociación se podría definir como el momento en que dos objetos se unen para trabajar juntos y así, alcanzar una meta.
Un punto a tomar muy en cuenta es que ambos objetos son independientes entre sí, veremos un poco más adelante qué implicación tiene esto. Para validar la asociación, la frase “Usa un”, debe tener sentido:
El ingeniero usa una computadora
El cliente usa tarjeta de crédito.
Composición
En caso contrario, la composición es un tipo de relación dependiente en dónde un objeto más complejo es conformado por objetos más pequeños. En esta situación, la frase “Tiene un”, debe tener sentido:
El auto tiene llantas
Y como ésta mini guía no va a mencionar nada de UML. Vamos a ver
directamente en código cómo se verían representadas ambos tipos de relaciones. El código es Java, pero funciona para cualquier lenguaje de programación
orientado a objetos.
Cómo implementar Asociación
Representaremos la relación: El cliente usa tarjeta de crédito.
Código :
public class Customer {
private int id;
private String firstName;
private String lastName;
private CreditCard creditCard;
public Customer() {
//Lo que sea que el construtor haga
}
public void setCreditCard(CreditCard creditCard) {
this.creditCard = creditCard;
}
}
La explicación viene más adelante para darles oportunidad que hagan sus propias comparaciones.
Cómo implementar Composición
Representaremos la relación: La portátil tiene un teclado.
Código :
public class Laptop {
private String manufacturer;
private String model;
private String serviceTag;
private KeyBoard keyBoard = new KeyBoard();
public Laptop() {
//Lo que sea que el constructor haga
}
}
Muy similar, pero hay una gran diferencia: Podemos crear un objeto de tipo
Customer y asignarle un CreditCard más tarde mediante el método setCreditCard.
Pero si creamos un objeto Laptop, de entrada sabremos que tendrá un teclado ya creado, puesto que la variable de referencia keyBoad es declarada e inicializada
al mismo tiempo.
Llamaremos a las clases Customer y Laptop, clases contenedoras. De ambos casos podemos deducir que:
En la asociación:
1. Customer es independiente de CreditCard, puesto que el cliente puede
existir sin necesidad de tener asignada una tarjeta de crédito. Démosle tiempo para que la tramite, ¡Pero no lo dejemos ir!
2. Se puede asignar o retirar la tarjeta de crédito, sin que la existencia del Cliente se vea afectada (No debería verse afectada, esto significa
que Customerno debe tronar si no hay un CreditCard presente).
En la composición:
1. Los objetos que componen a la clase contenedora, deben existir desde el principio. (También pueden ser creados en el constructor, no sólo al momento de declarar las variables como se muestra en el ejemplo).
2. No hay momento (No debería) en que la clase contenedora pueda existir sin alguno de sus objetos componentes. Por lo que la existencia de estos objetos no debe ser abiertamente manipulada desde el exterior de la clase.
Tiempo de vida de un objeto
Para que quede más clara la diferencia entre Asociación y Composición, entendamos además, lo que es el tiempo de vida de un objeto.
Se define como el tiempo que transcurre desde que un objeto es creado hasta que se destruye.
Aplicando esto a la asociación, tenemos que los tiempos de vida de ambos
objetos se cruzan mientras están trabajando juntos, esto es, mientras se encuentran asociados, pero no significa que se hayan creado al mismo tiempo. En el ejemplo del cliente, puede ser que primero se cree el cliente, después la
tarjeta de crédito y luego viene la asociación. O incluso se puede crear antes la tarjeta de crédito. Sus tiempos de vida se cruzan sólo mientras la tarjeta de crédito está asociada al cliente.
En la composición, tanto los objetos componentes como la clase contenedora,
nacen y mueren al mismo tiempo. Esto es, tienen el mismo tiempo de vida. Al ser una relación demasiado dependiente, si cualquier objeto muere, se lleva consigo a todos los demás. En el ejemplo de la portátil, si mi teclado se
descompone, mi laptop ya no es funcional.
Y no vengan con que puedo reemplazar el teclado, y que puedo seguir trabajando con la misma portátil y un teclado distinto. Tienes que analizarlo de la siguiente forma:
Si a tu auto, se le poncha una llanta, podrás reemplazarlas siempre y cuando lo tengas estacionado (Es como modificar el código de la clase, el sistema no está en funcionamiento). Pero ¿Qué pasa si tu auto estuviera en marcha?, ¿puedes cambiarla al vuelo e impedir que el auto se detenga? No se puede, por lo tanto tu auto deja de cumplir su objetivo en ese momento y para fines prácticos, ya no sirve. Entonces es lo mismo con los objetos ya creados, no puedes reemplazarles componentes al vuelo porque no existe (no debería) mecanismo alguno en la definición de la clase, que te lo permita.
¿Asociación o Composición? … depende
Habrá casos en que será difícil determinar qué tipo de relación usar cuando ambas encajan:
Un reloj tiene manecillas
Un reloj usa manecillas (Para dar la hora, claro).
Así que debes tomar en cuenta qué tanta flexibilidad te daría implementar una u otra.
Desde el punto de vista de fabricante de relojes, necesito tener control sobre cada una de las piezas que conforman mis relojes; así, si alguna pieza sale defectuosa, puedo reemplazarla antes que mi producto llegue al mercado. Me conviene la asociación.
Pero desde el punto de vista de Consumidor final, Si mis manecillas se friegan, pues tiro el reloj entero y me compro uno nuevo. Lo vería como composición. Y terminaré diciendo lo mismo que dicen la mayoría de las lecturas que tratan este
tema:
Todo depende del cristal con que se mire (Más propiamente dicho, el que
necesites).
Pero espero y haya logrado darles una perspectiva más clara de cómo y cuándo aplicar Asociación y Composición.
Saludos.
¿Sabes SQL? ¿No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y más
con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.
Agregación Vs Composición en diagramas de
clases. UML.
Por José María Megino Barquinero En enero 25, 2013 En Informática 11 comentarios
Una duda que frecuentemente me plantean los alumnos a la hora de modelar diagramas de clases con UML (Unified Modeling Language), es el uso de las relaciones estructurales de agregación y composición. Se trata de dos tipos de especialización de la relación de asociación entre clases.
Vamos a intentar mediante algunos ejemplos muy simples y esclarecedores, ver las diferencias que existen entre la composición fuerte y la composición débil, conocida habitualmente como agregación.
Agregación
La agregación es un tipo de asociación que indica que una clase es parte de otra clase (composición débil). Los componentes pueden ser compartidos por varios compuestos (de la misma asociación de agregación o de varias asociaciones de agregación distintas). La destrucción del compuesto no conlleva la destrucción de los componentes. Habitualmente se da con mayor frecuencia que la composición. La agregación se representa en UML mediante un diamante de color blanco colocado en el extremo en el que está la clase que representa el “todo”.
Veamos un ejemplo de agregación:
• Tenemos una clase Empresa. • Tenemos una clase Cliente.
• Una empresa agrupa a varios clientes.
Composición
Composición es una forma fuerte de composición donde la vida de la clase contenida debe coincidir con la vida de la clase contenedor. Los componentes constituyen una parte del objeto compuesto. De esta forma, los componentes no pueden ser compartidos por varios objetos compuestos. La supresión del objeto compuesto conlleva la supresión de los componentes.
El símbolo de composición es un diamante de color negro colocado en el extremo en el que está la clase que representa el “todo” (Compuesto).
• Tenemos una clase Empresa.
• Un objeto Empresa está a su vez compuesto por uno o varios objetos del tipo empleado.
• El tiempo de vida de los objetos Empleado depende del tiempo de vida de Empresa, ya que si no existe una Empresa no pueden existir sus empleados.
Diferencias entre Composición y Agregación
La siguiente tabla intenta resumir algunas diferencias entre agregación y composición.
Y en código…
Para traducir ambas relaciones a código, podemos utilizar un atributo en la clase contenedora o compuesta donde almacenaremos una colección de los objetos que la componen, y por otro lado declararemos un método para agregar elementos a la colección. Dependiendo del lenguaje de programación empleado, podemos utilizar diferentes estructuras de datos que nos permitan almacenar esa colección de objetos, aunque generalmente se utilizan arrays (arreglos) para este fin. Veamos un ejemplo:
Como podemos apreciar, es tan simple como crear en la clase Empresa un atributo clientes (colección de clientes) que sea un array, luego creamos un método
addCliente donde recibiremos objetos de tipo Cliente y los agregaremos dentro del array.
Concluyendo…
En líneas generales, como hemos visto, se podría decir que la diferencia entre
agregación y composición es conceptual, no se diferencia por código, o al
menos, en el mayor de los casos y en la mayoría de los lenguajes de programación (como Java o PHP). De todas maneras, en el caso de la composición, si quisiéramos ser más estrictos con los diagramas de clases modelados con UML, deberíamos destruir de alguna manera el objeto componente (empleado) una vez que se desasociaran del objeto compuesto (empresa).
En definitiva, UML nos permite la posibilidad de diferenciar este tipo de
asociaciones con el fin de que, aquella persona que le interese, pueda estipular de una u otra manera que se trata de una composición o una agregación, aunque en términos de implementación no se diferencie tan apenas su uso ni tenga tanta relevancia. Pero una vez más, y como vimos en un post anterior de este blog: “UML
en su justa medida…” , UML propone muchas posibilidades y debe ser el analista
y/o desarrollador quien decida y haga un uso correcto del mismo, con el fin de visualizar, especificar, construir y documentar adecuadamente los artefactos (modelos) de un sistema software.
Todo esto y mucho más, se estudia en el curso de Experto en gestión y desarrollo
