¿Cuál es la diferencia entre asociación, agregación y composición?

¿Cuál es la diferencia entre asociación, agregación y composición? Por favor explique en términos de implementación.

Para dos objetos, Fooy Barlas relaciones se pueden definir

Asociación : tengo una relación con un objeto. FoousosBar

public class Foo { 
    void Baz(Bar bar) {
    } 
};

Composición : soy dueño de un objeto y soy responsable de su vida útil. Cuando Foomuere, también lo haceBar

public class Foo {
    private Bar bar = new Bar(); 
}

Agregación : tengo un objeto que he tomado prestado de otra persona. Cuando Foomuere, Barpuede vivir.

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}

Sé que esta pregunta está etiquetada como C #, pero los conceptos son preguntas bastante genéricas como esta redirección aquí. Así que voy a proporcionar mi punto de vista aquí (un poco sesgado desde el punto de vista de Java, donde estoy más cómodo).

Cuando pensamos en la naturaleza orientada a objetos, siempre pensamos en objetos, clase (planos de objetos) y la relación entre ellos. Los objetos están relacionados e interactúan entre sí a través de métodos. En otras palabras, el objeto de una clase puede usar servicios / métodos proporcionados por el objeto de otra clase. Este tipo de relación se denomina asociación. .

La agregación y la composición son subconjuntos de asociación, lo que significa que son casos específicos de asociación.

• Tanto en la agregación como en la composición, el objeto de una clase "posee" el objeto de otra clase .
• Pero hay una sutil diferencia. En Composición, el objeto de clase que es propiedad del objeto de su clase no puede vivir solo (también llamado "relación de muerte"). Siempre vivirá como parte de su objeto propietario donde, como en la agregación, el objeto dependiente es independiente y puede existir incluso si el objeto de la clase propietaria está muerto.
• Entonces, en la composición, si el objeto propietario es basura recolectada, el objeto propietario también será, lo que no es el caso en la agregación.

¿Confuso?

Ejemplo de composición : Considere el ejemplo de un automóvil y un motor que es muy específico para ese automóvil (lo que significa que no puede usarse en ningún otro automóvil). Este tipo de relación entre Car y la clase SpecificEngine se llama Composición. Un objeto de la clase Car no puede existir sin un objeto de la clase SpecificEngine y el objeto de SpecificEngine no tiene significado sin la clase Car. Para poner en palabras simples, la clase Car únicamente "posee" la clase SpecificEngine.

Agregación Ejemplo : Consideremos ahora la clase de coches y la clase de la rueda . El automóvil necesita un objeto Wheel para funcionar. Lo que significa que el objeto Car posee el objeto Wheel pero no podemos decir que el objeto Wheel no tiene significado sin el objeto Car. Se puede usar muy bien en una bicicleta, camión u otro objeto de automóvil.

Resumiendo -

Para resumir, asociación es un término muy genérico que se usa para representar cuando una clase usa las funcionalidades proporcionadas por otra clase. Decimos que es composición si un objeto de clase padre posee otro objeto de clase hijo y ese objeto de clase hijo no puede existir significativamente sin el objeto de clase padre. Si puede, se llama Agregación.

Más detalles aquí. Soy el autor de http://opensourceforgeeks.blogspot.in y he agregado un enlace arriba a la publicación relevante para más contexto.

La asociación es un concepto generalizado de relaciones. Incluye tanto composición como agregación.

La composición ( mezcla ) es una forma de envolver objetos simples o tipos de datos en una sola unidad . Las composiciones son un componente fundamental de muchas estructuras de datos básicas.

La agregación ( colección ) difiere de la composición ordinaria en que no implica propiedad. En composición, cuando el objeto propietario se destruye, también lo son los objetos contenidos. En la agregación, esto no es necesariamente cierto.

Ambos denotan relación entre objeto y solo difieren en su fuerza.

Truco para recordar la diferencia: tiene A - A agregación y O wn - c O mpositoin

Ahora observemos la siguiente imagen

Analogía:

Composición : La siguiente imagen es la composición de la imagen, es decir, el uso de imágenes individuales que forman una imagen.

Agregación : colección de imágenes en una sola ubicación.

Por ejemplo, una universidad posee varios departamentos, y cada departamento tiene varios profesores. Si la universidad cierra, los departamentos ya no existirán, pero los profesores en esos departamentos continuarán existiendo. Por lo tanto, una universidad puede verse como una composición de departamentos, mientras que los departamentos tienen una agregación de profesores. Además, un profesor podría trabajar en más de un departamento, pero un departamento no podría ser parte de más de una universidad.

Dependencia (referencias)
Significa que no hay un vínculo conceptual entre dos objetos. Por ejemplo, referencias de objetos EnrollmentService Objetos de estudiantes y cursos (como parámetros de métodos o tipos de retorno)

public class EnrollmentService {
    public void enroll(Student s, Course c){}
}

Asociación (has-a)
Significa que casi siempre hay un vínculo entre los objetos (están asociados). El objeto de pedido tiene un objeto de cliente

public class Order {
    private Customer customer
}

Agregación (has-a + parte completa)
Tipo especial de asociación donde hay una relación de parte completa entre dos objetos. aunque podrían vivir el uno sin el otro.

public class PlayList{
    private List<Song> songs;
}

Nota: la parte más difícil es distinguir la agregación de la asociación normal. Honestamente, creo que esto está abierto a diferentes interpretaciones.

Composición (has-a + Whole-Part + propiedad) Tipo
especial de agregación. Un Apartmentse compone de algunos Rooms. A Roomno puede existir sin un Apartment. cuando se elimina un apartamento, también se eliminan todas las habitaciones asociadas.

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}

De una publicación de Robert Martin en comp.object :

La asociación representa la capacidad de una instancia para enviar un mensaje a otra instancia. Esto normalmente se implementa con un puntero o una variable de instancia de referencia, aunque también podría implementarse como un argumento de método o la creación de una variable local.

//[Example:]

//|A|----------->|B|

class A
{
  private:
    B* itsB;
};

La agregación [...] es la típica relación total / parcial. Esto es exactamente lo mismo que una asociación con la excepción de que las instancias no pueden tener relaciones de agregación cíclica (es decir, una parte no puede contener su totalidad).

//[Example:]

//|Node|<>-------->|Node|

class Node
{
  private:
    vector<Node*> itsNodes;
};

El hecho de que esto sea agregación significa que las instancias de Node no pueden formar un ciclo. Por lo tanto, este es un árbol de nodos, no un gráfico de nodos.

La composición [...] es exactamente como la agregación, excepto que la vida útil de la 'parte' está controlada por el 'todo'. Este control puede ser directo o transitivo. Es decir, el 'todo' puede asumir la responsabilidad directa de crear o destruir la 'parte', o puede aceptar una parte ya creada, y luego pasarla a otro todo que asume la responsabilidad de la misma.

//[Example:]

//|Car|<#>-------->|Carburetor|

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};

Como otros dijeron, una asociación es una relación entre objetos, la agregación y la composición son tipos de asociación.

Desde el punto de vista de la implementación, se obtiene una agregación al tener un miembro de clase por referencia . Por ejemplo, si la clase A agrega un objeto de la clase B, tendrá algo como esto (en C ++):

class A {
    B & element;
  // or B * element;
};

La semántica de la agregación es que cuando un objeto A se destruye, el objeto B que está almacenando seguirá existiendo. Cuando usa composición, tiene una relación más fuerte, generalmente almacenando el miembro por valor :

class A {
    B element;
};

Aquí, cuando se destruye un objeto A, el objeto B que contiene también se destruirá. La forma más fácil de lograr esto es almacenando el miembro por valor, pero también podría usar un puntero inteligente o eliminar el miembro en el destructor:

class A {
    std::auto_ptr<B> element;
};

class A {
    B * element;

    ~A() {
        delete B;
    }
};

El punto importante es que en una composición, el objeto contenedor posee el contenido, mientras que en la agregación, lo referencia .

Es sorprendente cuánta confusión existe sobre la distinción entre los tres conceptos de relación asociación , agregación y composición .

Observe que los términos agregación y composición se han utilizado en la comunidad C ++, probablemente durante algún tiempo antes de que se hayan definido como casos especiales de asociación en los Diagramas de clases UML.

El problema principal es el malentendido generalizado y continuo (incluso entre los desarrolladores expertos de software) de que el concepto de composición implica una dependencia del ciclo de vida entre el todo y sus partes, de modo que las partes no pueden existir sin el todo, ignorando el hecho de que también existen casos de asociaciones de partes enteras con partes no compartibles donde las partes se pueden separar y sobrevivir a la destrucción del todo.

Hasta donde puedo ver, esta confusión tiene dos raíces:

1. En la comunidad C ++, el término "agregación" se utilizó en el sentido de una clase que define un atributo para hacer referencia a objetos de otra clase independiente (véase, por ejemplo, [1]), que es el sentido de asociación en los Diagramas de clase UML. El término "composición" se usó para clases que definen objetos componentes para sus objetos, de modo que al destruir el objeto compuesto, estos objetos componentes también se destruyen.

2. En los Diagramas de clase UML, tanto "agregación" como "composición" se han definido como casos especiales de asociaciones que representan relaciones parte-todo (que se han discutido en filosofía durante mucho tiempo). En sus definiciones, la distinción entre una "agregación" y una "composición" se basa en el hecho de que permite compartir una parte entre dos o más totalidades. Definen "composiciones" como partes no compartibles (exclusivas), mientras que las "agregaciones" pueden compartir sus partes. Además, dicen algo como lo siguiente: muy a menudo, pero no en todos los casos, las composiciones vienen con una dependencia del ciclo de vida entre el todo y sus partes, de modo que las partes no pueden existir sin el todo.

Por lo tanto, si bien UML ha puesto los términos "agregación" y "composición" en el contexto correcto (de las relaciones parte-todo), no han logrado definirlos de una manera clara e inequívoca, capturando las intuiciones de los desarrolladores. Sin embargo, esto no es sorprendente porque hay muchas propiedades diferentes (y matices de implementación) que estas relaciones pueden tener, y los desarrolladores no están de acuerdo sobre cómo implementarlas.

Vea también mi respuesta extendida a la pregunta SO de abril de 2009 que se detalla a continuación.

Y la propiedad que se suponía que definía la "composición" entre los objetos OOP en la comunidad C ++ (y esta creencia aún se mantiene ampliamente): la dependencia del ciclo de vida en tiempo de ejecución entre los dos objetos relacionados (el compuesto y su componente), es no es realmente característico para la "composición" porque podemos tener tales dependencias debido a la integridad referencial también en otros tipos de asociaciones.

Por ejemplo, se propuso el siguiente patrón de código para "composición" en una respuesta SO :

final class Car {    
  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

El encuestado afirmó que sería característico de la "composición" que ninguna otra clase pudiera hacer referencia / conocer el componente. Sin embargo, esto ciertamente no es cierto para todos los casos posibles de "composición". En particular, en el caso del motor de un automóvil, el fabricante del automóvil, posiblemente implementado con la ayuda de otra clase, puede tener que hacer referencia al motor para poder contactar al propietario del automóvil siempre que haya un problema con él.

[1] http://www.learncpp.com/cpp-tutorial/103-aggregation/

Apéndice: lista incompleta de preguntas repetidas sobre composición versus agregación en StackOverflow

[ Abr 2009 ]
Agregación versus Composición [cerrado principalmente basado en la opinión por]
[ Abr 2009 ]
¿Cuál es la diferencia entre la composición y la relación de asociación?
[ Mayo de 2009 ]
Diferencia entre asociación, agregación y composición
[ Mayo de 2009 ]
¿Cuál es la diferencia entre composición y agregación? [duplicado]
[ Oct 2009 ]
¿Cuál es la diferencia entre agregación, composición y dependencia? [marcado como duplicado]
[ Nov 2010 ]
Asociación vs. Agregación [marcado como duplicado]
[Ago 2012 ]
Diferencia de implementación entre Agregación y Composición en Java
[ Feb 2015 ]
UML - asociación o agregación (fragmentos de código simples)

Asociación

La asociación representa la relación entre dos clases. Puede ser unidireccional (unidireccional) o bidireccional (bidireccional)

por ejemplo:

1. unidireccional

El cliente realiza pedidos

2. bidireccional

A está casado con B

B está casado con A

Agregación

La agregación es un tipo de asociación. Pero con características específicas. La agregación es la relación en una clase "entera" más grande que contiene una o más clases "partes" más pequeñas. Por el contrario, una clase "parte" más pequeña es parte de una clase más grande "entera" .

por ejemplo:

el club tiene miembros

Un club ("todo") está compuesto por varios miembros del club ("partes"). Los miembros tienen vida fuera del club. Si el club ("entero") muriera, los miembros ("partes") no morirían con él. Porque el miembro puede pertenecer a varios clubes ("todo").

Composición

Esta es una forma más fuerte de agregación. "Whole" es responsable de la creación o destrucción de sus "partes"

Por ejemplo:

Una escuela tiene departamentos.

En este caso, la escuela ("entera") moriría, el departamento ("partes") moriría con ella. Porque cada parte puede pertenecer a un solo "todo".

Es importante entender por qué incluso deberíamos molestarnos en usar más de una línea de relación. La razón más obvia es describir la relación padre-hijo entre las clases (cuando el padre eliminó a todos los hijos como resultado), pero de manera más impotente, queremos distinguir entre asociación simple y composición para colocar restricciones implícitas en la visibilidad y propagación de cambios a las clases relacionadas, un asunto que juega un papel importante en la comprensión y la reducción de la complejidad del sistema.

Asociación

La forma más abstracta de describir la relación estática entre clases es mediante el enlace de Asociación, que simplemente establece que existe algún tipo de enlace o dependencia entre dos clases o más.

Asociación débil

La Clase A puede estar vinculada a la Clase B para mostrar que uno de sus métodos incluye el parámetro de la instancia de la Clase B, o devuelve la instancia de la Clase B.

Asociación fuerte

ClassA también puede estar vinculado a ClassB para mostrar que tiene una referencia a la instancia de ClassB.

Agregación (Asociación compartida)

En los casos en que existe una relación parcial entre ClassA (total) y ClassB (parte), podemos ser más específicos y utilizar el enlace de agregación en lugar del enlace de asociación, destacando que ClassB también puede agregarse por otras clases en la aplicación ( por lo tanto, la agregación también se conoce como asociación compartida).

Es importante tener en cuenta que el enlace de agregación no indica de ninguna manera que ClassA posee ClassB ni que existe una relación padre-hijo (cuando el padre eliminó a todos sus hijos se eliminan como resultado) entre los dos. En realidad, todo lo contrario! El enlace de agregación generalmente se usa para enfatizar el punto de que ClassA no es el contenedor exclusivo de ClassB, ya que de hecho ClassB tiene otro contenedor.

Agregación vs Asociación El enlace de asociación puede reemplazar el enlace de agregación en cada situación, mientras que la agregación no puede reemplazar la asociación en situaciones donde solo hay un 'enlace débil' entre las clases, es decir, ClassA tiene métodos que contienen parámetros de ClassB pero ClassA no mantenga referencia a la instancia de ClassB.

Martin Fowler sugiere que el enlace de agregación no debe usarse en absoluto porque no tiene valor agregado y perturba la consistencia, citando a Jim Rumbaugh "Piense en ello como un placebo de modelado".

Composición (Asociación no compartida)

Deberíamos ser más específicos y utilizar el enlace de composición en los casos en que, además de la parte de la relación entre ClassA y ClassB, existe una fuerte dependencia del ciclo de vida entre los dos, lo que significa que cuando se elimina ClassA, entonces también se elimina ClassB.

El enlace de composición muestra que una clase (contenedor, todo) tiene propiedad exclusiva sobre otra clase / s (partes), lo que significa que el objeto contenedor y sus partes constituyen una relación padre-hijo / s.

A diferencia de la asociación y la agregación, cuando se usa la relación de composición, la clase compuesta no puede aparecer como un tipo de retorno o tipo de parámetro de la clase compuesta. Por lo tanto, los cambios en la clase compuesta no pueden propagarse al resto del sistema. En consecuencia, el uso de la composición limita el crecimiento de la complejidad a medida que el sistema crece.

Sistema de medición de la complejidad

La complejidad del sistema se puede medir simplemente mirando un diagrama de clase UML y evaluando las líneas de relación de asociación, agregación y composición. La forma de medir la complejidad es determinar cuántas clases pueden verse afectadas al cambiar una clase en particular. Si la clase A expone a la clase B, cualquier clase dada que use la clase A puede verse afectada teóricamente por los cambios en la clase B. La suma del número de clases potencialmente afectadas para cada clase en el sistema es la complejidad total del sistema.

Puede leer más en mi blog: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

Composición (Si elimina "todo", "parte" también se elimina automáticamente: "Propiedad")

• Cree objetos de su clase existente dentro de la nueva clase. Esto se llama composición porque la nueva clase está compuesta de objetos de clases existentes.

• Por lo general, use variables miembro normales.

• Puede usar valores de puntero si la clase de composición maneja automáticamente la asignación / desasignación responsable de la creación / destrucción de subclases.

Composición en C ++

#include <iostream>
using namespace std;
/********************** Engine Class ******************/
class Engine
{
    int nEngineNumber;
    public:
    Engine(int nEngineNo);
    ~Engine(void);
};
Engine::Engine(int nEngineNo)
{
    cout<<" Engine :: Constructor " <<endl;
}
Engine::~Engine(void)
{
    cout<<" Engine :: Destructor " <<endl;
}
/********************** Car Class ******************/
class Car
{
    int nCarColorNumber;
    int nCarModelNumber;
    Engine objEngine;
    public:
    Car (int, int,int);
    ~Car(void);
};
Car::Car(int nModelNo,int nColorNo, int nEngineNo):
nCarModelNumber(nModelNo),nCarColorNumber(nColorNo),objEngine(nEngineNo)
{
    cout<<" Car :: Constructor " <<endl;
}
Car::~Car(void)
{
    cout<<" Car :: Destructor " <<endl;
    Car
    Engine
    Figure 1 : Composition
}
/********************** Bus Class ******************/
class Bus
{
    int nBusColorNumber;
    int nBusModelNumber;
    Engine* ptrEngine;
    public:
    Bus(int,int,int);
    ~Bus(void);
};
Bus::Bus(int nModelNo,int nColorNo, int nEngineNo):
nBusModelNumber(nModelNo),nBusColorNumber(nColorNo)
{
    ptrEngine = new Engine(nEngineNo);
    cout<<" Bus :: Constructor " <<endl;
}
Bus::~Bus(void)
{
    cout<<" Bus :: Destructor " <<endl;
    delete ptrEngine;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    // Composition using simple Engine in a car object
    {
        cout<<"------------- Inside Car Block ------------------"<<endl;
        Car objCar (1, 2,3);
    }
    cout<<"------------- Out of Car Block ------------------"<<endl;
    // Composition using pointer of Engine in a Bus object
    {
        cout<<"------------- Inside Bus Block ------------------"<<endl;
        Bus objBus(11, 22,33);
    }
    cout<<"------------- Out of Bus Block ------------------"<<endl;
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Salida

--------------- Start Of Program --------------------
------------- Inside Car Block ------------------
Engine :: Constructor
Car :: Constructor
Car :: Destructor
Engine :: Destructor
------------- Out of Car Block ------------------
------------- Inside Bus Block ------------------
Engine :: Constructor
Bus :: Constructor
Bus :: Destructor
Engine :: Destructor
------------- Out of Bus Block ------------------
--------------- End Of Program --------------------

Agregación (si elimina "todo", "Parte" puede existir - "Sin propiedad")

• Una agregación es un tipo específico de composición donde no se implica propiedad entre el objeto complejo y los subobjetos. Cuando se destruye un agregado, los subobjetos no se destruyen.

• Por lo general, use variables de puntero / variables de referencia que apuntan a un objeto que vive fuera del alcance de la clase agregada

• Puede usar valores de referencia que apuntan a un objeto que vive fuera del alcance de la clase agregada

• No nos hacemos responsables de crear / destruir subclases

Código de agregación en C ++

#include <iostream>
#include <string>
using namespace std;
/********************** Teacher Class ******************/
class Teacher
{
    private:
    string m_strName;
    public:
    Teacher(string strName);
    ~Teacher(void);
    string GetName();
};
Teacher::Teacher(string strName) : m_strName(strName)
{
    cout<<" Teacher :: Constructor --- Teacher Name :: "<<m_strName<<endl;
}
Teacher::~Teacher(void)
{
    cout<<" Teacher :: Destructor --- Teacher Name :: "<<m_strName<<endl;
}
string Teacher::GetName()
{
    return m_strName;
}
/********************** Department Class ******************/
class Department
{
    private:
    Teacher *m_pcTeacher;
    Teacher& m_refTeacher;
    public:
    Department(Teacher *pcTeacher, Teacher& objTeacher);
    ~Department(void);
};
Department::Department(Teacher *pcTeacher, Teacher& objTeacher)
: m_pcTeacher(pcTeacher), m_refTeacher(objTeacher)
{
    cout<<" Department :: Constructor " <<endl;
}
Department::~Department(void)
{
    cout<<" Department :: Destructor " <<endl;
}
/********************** Main Function ******************/
int main()
{
    freopen ("InstallationDump.Log", "w", stdout);
    cout<<"--------------- Start Of Program --------------------"<<endl;
    {
        // Create a teacher outside the scope of the Department
        Teacher objTeacher("Reference Teacher");
        Teacher *pTeacher = new Teacher("Pointer Teacher"); // create a teacher
        {
            cout<<"------------- Inside Block ------------------"<<endl;
            // Create a department and use the constructor parameter to pass the teacher to it.
            Department cDept(pTeacher,objTeacher);
            Department
            Teacher
            Figure 2: Aggregation
        } // cDept goes out of scope here and is destroyed
        cout<<"------------- Out of Block ------------------"<<endl;
        // pTeacher still exists here because cDept did not destroy it
        delete pTeacher;
    }
    cout<<"--------------- End Of Program --------------------"<<endl;
    fclose (stdout);
}

Salida

--------------- Start Of Program --------------------
Teacher :: Constructor --- Teacher Name :: Reference Teacher
Teacher :: Constructor --- Teacher Name :: Pointer Teacher
------------- Inside Block ------------------
Department :: Constructor
Department :: Destructor
------------- Out of Block ------------------
Teacher :: Destructor --- Teacher Name :: Pointer Teacher
Teacher :: Destructor --- Teacher Name :: Reference Teacher
--------------- End Of Program --------------------

El problema con estas respuestas es que son la mitad de la historia: explican que la agregación y la composición son formas de asociación, pero no dicen si es posible que una asociación no sea ninguna de esas.

En base a algunas lecturas breves de muchas publicaciones en SO y algunos documentos UML, deduzco que hay 4 formas concretas principales de asociación de clases:

1. composición: A está compuesto de a B; B no existe sin A, como una habitación en un hogar
2. agregación: A tiene-a B; B puede existir sin A, como un estudiante en un aula
3. dependencia: A usa-a B; sin dependencia del ciclo de vida entre A y B, como un parámetro de llamada al método, un valor de retorno o un temporal creado durante una llamada al método
4. generalización: A es-a B

Cuando una relación entre dos entidades no es una de estas, simplemente se puede llamar "una asociación" en el sentido genérico del término, y se describen otras formas (nota, estereotipo, etc.).

Supongo que la "asociación genérica" ​​está destinada a usarse principalmente en dos circunstancias:

• cuando los detalles de una relación todavía se están resolviendo; dicha relación en un diagrama debe convertirse lo antes posible a lo que realmente es / será (uno de los otros 4).
• cuando una relación no coincide con ninguno de los 4 predeterminados por UML; la asociación "genérica" ​​aún le brinda una forma de representar una relación que "no es una de las otras", de modo que no esté atrapado usando una relación incorrecta con una nota "esto no es realmente agregación, es solo ese UML no tiene ningún otro símbolo que podamos usar "

Creo que este enlace hará su tarea: http://ootips.org/uml-hasa.html

Para entender los términos, recuerdo un ejemplo en mis primeros días de programación:

Si tiene un objeto 'tablero de ajedrez' que contiene objetos 'caja' que es composición porque si se elimina el 'tablero de ajedrez' ya no hay razón para que las cajas existan.

Si tiene un objeto 'cuadrado' que tiene un objeto 'color' y el cuadrado se elimina, el objeto 'color' aún puede existir, es decir, la agregación

Ambos son asociaciones , la principal diferencia es conceptual

Composición : Aquí es donde una vez que destruyes un objeto (Escuela), otro objeto (Aulas) que está vinculado a él también se destruirá. Ambos no pueden existir de forma independiente.

Agregación : Esto es más o menos exactamente lo contrario de la Compositionasociación anterior ( ) donde una vez que matas un objeto ( Company), el otro objeto ( Employees) que está vinculado a él puede existir por sí solo.

Asociación .
Composición y agregación son las dos formas de asociación.

    Simple rules:
    A "owns" B = Composition : B has no meaning or purpose in the system 
    without A
    A "uses" B = Aggregation : B exists independently (conceptually) from A
    A "belongs/Have" B= Association; And B exists just have a relation
    Example 1:

    A Company is an aggregation of Employees.
    A Company is a composition of Accounts. When a Company ceases to do 
    business its Accounts cease to exist but its People continue to exist. 
    Employees have association relationship with each other.

    Example 2: (very simplified)
    A Text Editor owns a Buffer (composition). A Text Editor uses a File 
    (aggregation). When the Text Editor is closed,
    the Buffer is destroyed but the File itself is not destroyed.

En una oración muy simple:
Agregación y Composición son subconjuntos de asociación.

• A usa B -> esta es una agregación

• A necesita B -> es composición.

Lee más aquí .

Me gustaría ilustrar cómo se implementan los tres términos en Rails. ActiveRecord llama a cualquier tipo de relación entre dos modelos y association. No se encuentran muy a menudo los términos compositiony aggregation, al leer documentación o artículos, se relacionan con ActiveRecord. Una asociación se crea al agregar una de las macros de clase de asociación al cuerpo de la clase. Algunas de estas macros son belongs_to, has_one, has_manyetc ..

Si queremos configurar un compositiono aggregation, necesitamos agregarlo belongs_toal modelo propio (también llamado hijo) y / has_oneo has_manyal modelo propietario (también llamado padre). Ya sea que configuremos compositiono aggregationdependa de las opciones que pasamos a la belongs_tollamada en el modelo secundario. Antes de Rails 5, la configuración belongs_tosin ninguna opción creada aggregation, el niño podría existir sin un padre. Si queríamos un composition, necesitábamos declarar esto explícitamente agregando la opción required: true:

class Room < ActiveRecord::Base
  belongs_to :house, required: true
end

En Rails 5 esto fue cambiado. Ahora, declarar una belongs_toasociación crea un compositionvalor predeterminado, el elemento secundario no puede existir sin un elemento primario. Entonces, el ejemplo anterior se puede volver a escribir como:

class Room < ApplicationRecord
  belongs_to :house
end

Si queremos permitir que el objeto hijo exista sin un padre, debemos declarar esto explícitamente a través de la opción optional

class Product < ApplicationRecord
  belongs_to :category, optional: true
end

Del libro de Remo H. Jansen "Beginning React: Learning TypeScript 2.x - Second Edition":

Llamamos asociación a aquellas relaciones cuyos objetos tienen un ciclo de vida independiente donde no hay propiedad de los objetos. Echemos un vistazo a un ejemplo de un maestro y un alumno. Se pueden asociar varios estudiantes con un solo maestro, y un solo estudiante se puede asociar con múltiples maestros, pero ambos tienen ciclos de vida independientes (ambos pueden crear y eliminar de forma independiente). Entonces, cuando un maestro abandona la escuela, no necesitamos eliminar a ningún alumno, y cuando un alumno abandona la escuela, no necesitamos eliminar a ningún maestro.

Llamamos agregación a aquellas relaciones cuyos objetos tienen un ciclo de vida independiente, pero existe la propiedad, y los objetos secundarios no pueden pertenecer a otro objeto primario. Tomemos un ejemplo de un teléfono celular y una batería de teléfono celular. Una sola batería puede pertenecer a un teléfono, pero si el teléfono deja de funcionar y la eliminamos de nuestra base de datos, la batería del teléfono no se eliminará porque aún puede funcionar. Entonces, en conjunto, mientras haya propiedad, los objetos tienen su ciclo de vida

Usamos el término composición para referirnos a relaciones cuyos objetos no tienen un ciclo de vida independiente, y si el objeto padre se elimina, todos los objetos secundarios también se eliminarán. Tomemos un ejemplo de la relación entre preguntas y respuestas. Las preguntas individuales pueden tener múltiples respuestas, y las respuestas no pueden pertenecer a múltiples preguntas. Si eliminamos preguntas, las respuestas se eliminarán automáticamente.

La asociación es una relación entre dos clases separadas y la asociación puede ser de cualquier tipo, digamos uno a uno, uno a mayo, etc. Se une a dos entidades completamente separadas.

La agregación es una forma especial de asociación que es una relación unidireccional unidireccional entre clases (o entidades), por ejemplo, clases Wallet y Money. Wallet tiene dinero, pero el dinero no necesita tener Wallet necesariamente, por lo que es una relación unidireccional. En esta relación, ambas entradas pueden sobrevivir si la otra termina. En nuestro ejemplo, si la clase Wallet no está presente, no significa que la clase Money no pueda existir.

La composición es una forma restringida de agregación en la que dos entidades (o puede decir clases) son altamente dependientes entre sí. Por ejemplo, humano y corazón. Un humano necesita un corazón para vivir y un corazón necesita un cuerpo humano para sobrevivir. En otras palabras, cuando las clases (entidades) dependen unas de otras y su vida útil es la misma (si una muere, entonces otra también), entonces es una composición. La clase del corazón no tiene sentido si la clase humana no está presente.

https://www.linkedin.com/pulse/types-relationships-object-oriented-programming-oop-sarah-el-dawody/

Composición: es una relación "parte de".

por ejemplo, "el motor es parte del automóvil", "el corazón es parte del cuerpo".

Asociación: es una relación de tipo "tiene-a"

Por ejemplo, supongamos que tenemos dos clases, entonces se dice que estas dos clases son relaciones "has-a" si ambas entidades comparten el objeto del otro para algún trabajo y al mismo tiempo pueden existir sin la dependencia del otro o ambas tienen su propia vida

El ejemplo anterior muestra una relación de asociación debido a que tanto la clase Empleado como el Administrador usan el objeto de cada uno y ambos su propio ciclo de vida independiente.

La agregación: se basa en una relación "tiene-a" y es \\ una forma especial de asociación

por ejemplo, "Estudiante" y "dirección". Cada estudiante debe tener una dirección para que la relación entre la clase de estudiante y la clase de dirección sea de tipo "Has-A", pero viceversa no es cierto.