Programacin Orientada a Objetos: Asociacin vs ComposicinPorDarelel 14 de Julio de 2010con 47,275 visitas

Tecnologia y otrosOtros tutoriales por Darel.En lo personal, conceptos que me parecieron bastante difciles de comprender cada vez que trataba de estudiarProgramacin Orientada a Objetos. Por eso tratar de crear una explicacin sencilla para los que ahora se ven en mi situacin. Porque el que domines un lenguaje de programacin no te garantiza que hars un buen diseo del sistema.

Los dos conceptos que debes conocer cmo mnimo cuando intentas descifrar la forma en que tus objetos deben interactuar sonAsociacinyComposicin.Asociacin

La asociacin se podra 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 ms adelante qu implicacin tiene esto. Para validar la asociacin, la fraseUsa un, debe tener sentido: El ingenierousauna computadora El clienteusatarjeta de crdito.

Composicin

En caso contrario, la composicin es un tipo de relacindependienteen dnde un objeto ms complejo es conformado por objetos ms pequeos. En esta situacin, la frase Tiene un, debe tener sentido: El autotienellantas La porttiltieneun teclado.

Y como sta mini gua no va a mencionar nada deUML. Vamos a ver directamente en cdigo cmo se veran representadas ambos tipos de relaciones.

El cdigo es Java, pero funciona para cualquier lenguaje deprogramacin orientado a objetos.Cmo implementarAsociacin

Representaremos la relacin:El clienteusatarjeta de crdito.Cdigo :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; }

// Ms cdigo aqu}

La explicacin viene ms adelante para darles oportunidad que hagan sus propias comparaciones.Cmo implementarComposicin

Representaremos la relacin:La porttiltiene unteclado.Cdigo :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 ms tarde mediante el mtodo setCreditCard.

Pero si creamos un objetoLaptop, de entrada sabremos que tendr un teclado ya creado, puesto que la variable de referenciakeyBoades declarada e inicializada al mismo tiempo.

Llamaremos a las clasesCustomeryLaptop,clases contenedoras.

De ambos casos podemos deducir que:En la asociacin:

1. Customeres independiente deCreditCard, puesto que el cliente puede existir sin necesidad de tener asignada una tarjeta de crdito. Dmosle tiempo para que la tramite, Pero no lo dejemos ir!2. Se puede asignar o retirar la tarjeta de crdito, sin que la existencia del Cliente se vea afectada (No debera verse afectada, esto significa queCustomerno debe tronar si no hay unCreditCardpresente).

En la composicin:

1. Los objetos que componen a la clase contenedora, deben existir desde el principio. (Tambin pueden ser creados en el constructor, no slo al momento de declarar las variables como se muestra en el ejemplo).2. No hay momento (No debera) en que laclase contenedorapueda 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 ms clara la diferencia entre Asociacin y Composicin, entendamos adems, lo que es eltiempo 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 asociacin, tenemos que los tiempos de vida de ambos objetos se cruzan mientras estn 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, despus la tarjeta de crdito y luego viene la asociacin. O incluso se puede crear antes la tarjeta de crdito. Sus tiempos de vida se cruzan slo mientras la tarjeta de crdito est asociada al cliente.

En la composicin, 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 relacin demasiado dependiente, si cualquier objeto muere, se lleva consigo a todos los dems. En el ejemplo de la porttil, 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 porttil y un teclado distinto. Tienes que analizarlo de la siguiente forma:

Si a tu auto, se le poncha una llanta, podrs reemplazarlas siempre y cuando lo tengas estacionado (Es como modificar el cdigo 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 prcticos, ya no sirve. Entonces es lo mismo con los objetos ya creados, no puedes reemplazarles componentes al vuelo porque no existe (no debera) mecanismo alguno en la definicin de la clase, que te lo permita.Asociacin o Composicin? depende

Habr casos en que ser difcil determinar qu tipo de relacin usar cuando ambas encajan: Un relojtienemanecillas Un relojusamanecillas (Para dar la hora, claro).

As que debes tomar en cuenta qu tanta flexibilidad te dara 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 asociacin.

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 vera como composicin.

Y terminar diciendo lo mismo que dicen la mayora de las lecturas que tratan este tema:

Todo depende del cristal con que se mire(Ms propiamente dicho, el que necesites).

Pero espero y haya logrado darles una perspectiva ms clara de cmo y cundo aplicarAsociacinyComposicin.

Saludos.Sabes SQL? No-SQL?Aprende MySQL, PostgreSQL, MongoDB, Redis y ms con elCurso Profesional de Bases de Datosque empieza el martes, en vivo.

Agregacin Vs Composicin en diagramas de clases. UML.PorJos Mara Megino BarquineroEn enero 25, 2013EnInformtica11 comentariosUna 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 agregacin y composicin. Se trata de dos tipos de especializacin de la relacin de asociacin entre clases.Vamos a intentar mediante algunos ejemplos muy simples y esclarecedores, ver las diferencias que existen entre la composicin fuerte y la composicin dbil, conocida habitualmente como agregacin.AgregacinLa agregacin es un tipo de asociacin que indica que una clase es parte de otra clase (composicin dbil). Los componentes pueden ser compartidos por varios compuestos (de la misma asociacin de agregacin o de varias asociaciones de agregacin distintas). La destruccin del compuesto no conlleva la destruccin de los componentes. Habitualmente se da con mayor frecuencia que la composicin.La agregacin 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 agregacin:

Tenemos una clase Empresa. Tenemos una clase Cliente. Una empresa agrupa a varios clientes.ComposicinComposicin es una forma fuerte de composicin 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 supresin del objeto compuesto conlleva la supresin de los componentes.El smbolo de composicin es un diamante de color negro colocado en el extremo en el que est la clase que representa el todo (Compuesto).Veamos un ejemplo de composicin:

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 Composicin y AgregacinLa siguiente tabla intenta resumir algunas diferencias entre agregacin y composicin.

Y en cdigoPara traducir ambas relaciones a cdigo, podemos utilizar un atributo en la clase contenedora o compuesta donde almacenaremos una coleccin de los objetos que la componen, y por otro lado declararemos un mtodo para agregar elementos a la coleccin. Dependiendo del lenguaje de programacin empleado, podemos utilizar diferentes estructuras de datos que nos permitan almacenar esa coleccin 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 (coleccin de clientes) que sea un array, luego creamos un mtodo addCliente donde recibiremos objetos de tipo Cliente y los agregaremos dentro del array.ConcluyendoEn lneas generales, como hemos visto, se podra decir quela diferencia entre agregacin y composicin es conceptual, no se diferencia por cdigo, o al menos, en el mayor de los casos y en la mayora de los lenguajes de programacin (comoJavaoPHP). De todas maneras, en el caso de la composicin, si quisiramos ser ms estrictos con los diagramas de clases modelados con UML, deberamos 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 composicin o una agregacin, aunque en trminos de implementacin no se diferencie tan apenas su uso ni tenga tanta relevancia. Pero una vez ms, 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 ms, se estudia en el curso deExperto en gestin y desarrollo de aplicaciones informticas orientadas a objetos.