Programacin Orientada a Objetos:

Asociacin vs Composicin
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 difciles de comprender

cada vez que trataba de estudiar Programacin 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 son Asociacin yComposicin.

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 frase Usa un, debe tener sentido:

El ingeniero usa una computadora

El cliente usa tarjeta de crdito.

Composicin
En caso contrario, la composicin es un tipo de relacin dependiente en dnde un
objeto ms complejo es conformado por objetos ms pequeos. En esta situacin,
la frase Tiene un, debe tener sentido:

El auto tiene llantas

La porttil tiene un teclado.

Y como sta mini gua no va a mencionar nada de UML. Vamos a ver

directamente en cdigo cmo se veran representadas ambos tipos de relaciones.
El cdigo es Java, pero funciona para cualquier lenguaje de programacin
orientado a objetos.

Cmo implementar Asociacin

Representaremos la relacin: El cliente usa tarjeta 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 implementar Composicin

Representaremos la relacin: La porttil tiene un teclado.
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 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 asociacin:

1.

Customer es independiente de CreditCard, 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
que Customerno debe tronar si no hay un CreditCard presente).

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 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 ms clara la diferencia entre Asociacin y Composicin,
entendamos adems, 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 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 reloj tiene manecillas

Un reloj usa manecillas (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
aplicar Asociacin y Composicin.
Saludos.
Sabes SQL? No-SQL? Aprende MySQL, PostgreSQL, MongoDB, Redis y ms
con el Curso Profesional de Bases de Datos que empieza el martes, en vivo.

Agregacin Vs Composicin en diagramas de

clases. UML.
Por Jos Mara Megino Barquinero En enero 25, 2013 En Informtica 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 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.

Agregacin
La 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.

Composicin
Composicin 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 Agregacin

La siguiente tabla intenta resumir algunas diferencias entre agregacin y
composicin.

Y en cdigo
Para 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.

Concluyendo
En lneas generales, como hemos visto, se podra decir que la 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
(como Java o PHP). 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 de Experto en gestin y desarrollo

de aplicaciones informticas orientadas a objetos.