Explicación de la asociación, agregación y composición en OOP

El lenguaje de modelado unificado (UML) es un estándar de facto para modelar sistemas orientados a objetos. En UML hay cinco tipos diferentes de relaciones: asociación, agregación, composición, dependencia y herencia. Este artículo presenta una discusión de los primeros tres de estos conceptos, dejando los restantes para otra publicación del blog.

Asociación en programación orientada a objetos

La asociación es una relación semánticamente débil (una dependencia semántica) entre objetos que de otro modo no estarían relacionados. Una asociación es una relación de "uso" entre dos o más objetos en la que los objetos tienen su propia vida y no hay propietario.

Como ejemplo, imagine la relación entre un médico y un paciente. Un médico puede asociarse con varios pacientes. Al mismo tiempo, un paciente puede visitar a varios médicos para recibir tratamiento o consulta. Cada uno de estos objetos tiene su propio ciclo de vida y no hay "propietario" ni padre. Los objetos que forman parte de la relación de asociación se pueden crear y destruir de forma independiente.

En UML, una relación de asociación está representada por una sola flecha. Una relación de asociación se puede representar como uno a uno, uno a varios o varios a varios (también conocida como cardinalidad). Esencialmente, una relación de asociación entre dos o más objetos denota una ruta de comunicación (también llamada enlace) entre ellos para que un objeto pueda enviar un mensaje a otro. El siguiente fragmento de código ilustra cómo dos clases, BlogAccount y BlogEntry, están asociadas entre sí.

BlogAccount de clase pública

   {

       BlogEntry privado [] blogEntries;

       // Otros miembros de la clase BlogAccount

   }

BlogEntry de clase pública

   {

       Int32 blogId;

       título de cadena;

       texto de cadena;

       // Otros miembros de la clase BlogEntry

   }

Agregación en programación orientada a objetos

La agregación es una forma especializada de asociación entre dos o más objetos en la que cada objeto tiene su propio ciclo de vida, pero también existe una propiedad. La agregación es una relación típica de todo / parte o padre / hijo, pero puede o no denotar contención física. Una propiedad esencial de una relación de agregación es que el todo o el padre (es decir, el propietario) puede existir sin la parte o el hijo y viceversa.  

Por ejemplo, un empleado puede pertenecer a uno o más departamentos de una organización. Sin embargo, si se elimina el departamento de un empleado, el objeto del empleado no se destruirá, pero seguirá vivo. Tenga en cuenta que las relaciones entre los objetos que participan en una agregación no pueden ser recíprocas, es decir, un departamento puede "ser propietario" de un empleado, pero el empleado no es propietario del departamento. En el siguiente ejemplo de código, es evidente una relación de agregación entre las clases BlogAuthor y BlogAccount.

BlogAuthor de clase pública

   {

       authorId privado Int32;

       cadena privada firstName;

       lastName cadena privada;

       // Otros miembros de la clase BlogAuthor

   }

BlogAccount de clase pública

   {

       BlogEntry privado [] blogEntries;

       // Otros miembros de la clase BlogAccount

   }

La agregación generalmente se representa en UML mediante una línea con un diamante hueco. Al igual que la asociación, la agregación puede implicar una relación de uno a uno, de uno a varios o de varios a varios entre los objetos participantes. En el caso de una relación de uno a muchos o de muchos a muchos, podemos decir que es una relación redundante.

Composición en programación orientada a objetos

La composición es una forma especializada de agregación. En la composición, si el objeto principal se destruye, los objetos secundarios también dejan de existir. La composición es en realidad un tipo fuerte de agregación y, a veces, se la denomina relación de "muerte". Por ejemplo, una casa puede estar compuesta por una o más habitaciones. Si la casa se destruye, todas las habitaciones que forman parte de la casa también se destruyen. El siguiente fragmento de código ilustra una relación de composición entre dos clases, House y Room.

casa de clase pública

{

   habitación privada;

   casa publica()

   {

       habitación = nueva habitación ();

   }

}

Al igual que la agregación, la composición también es una relación todo / parte o padre / hijo. Sin embargo, en la composición, el ciclo de vida de la parte o el hijo está controlado por la totalidad o el padre que lo posee. Cabe señalar que este control puede ser directo o transitivo. Es decir, el padre puede ser directamente responsable de la creación o destrucción del hijo o el padre puede utilizar un hijo que ya ha sido creado. De manera similar, un objeto padre puede delegar el control a otro padre para destruir el objeto hijo. La composición se representa en UML mediante una línea que conecta los objetos con un diamante sólido al final del objeto que posee el otro objeto.

Espero que esta discusión sobre las relaciones de asociación, agregación y composición le haya ayudado a comprender en qué se diferencian estos tres conceptos. Recuerde que la agregación y la composición son ambos subconjuntos de asociación. Tanto en agregación como en composición, un objeto de una clase puede ser propietario de un objeto de otra clase. Y tanto en la agregación como en la composición, los objetos secundarios pertenecen a un único objeto principal, es decir, pueden tener un solo propietario.

Finalmente, en una relación de agregación, los ciclos de vida de los objetos principales y los objetos secundarios son independientes. En una relación de composición, la muerte de un objeto padre también significa la muerte de sus hijos.