associations - generalizacion - ¿Cuál es la diferencia entre asociación, agregación y composición?
generalizacion uml (17)
Como han dicho otros, 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, una agregación se obtiene 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 se destruye un objeto A, el objeto B que está almacenando seguirá existiendo. Cuando usa la 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 puede usar algún 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 la contenida, mientras que en la agregación, hace referencia a ella.
¿Cuál es la diferencia entre asociación, agregación y composición? Por favor explique en términos de implementación.
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 de "tablero de ajedrez" que contiene objetos de "caja" que es composición porque si se elimina el "tablero de ajedrez" no hay razón para que existan más cajas.
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
Ambas son asociaciones , la principal diferencia es conceptual.
De un post 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 se puede implementar 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 relación típica de todo / parte. 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íclicas (es decir, una parte no puede contener su totalidad).
//[Example:]
//|Node|<>-------->|Node|
class Node
{
private:
vector<Node*> itsNodes;
};
El hecho de que esto sea una 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 igual a 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 algún otro todo que asuma la responsabilidad.
//[Example:]
//|Car|<#>-------->|Carburetor|
class Car
{
public:
virtual ~Car() {delete itsCarb;}
private:
Carburetor* itsCarb
};
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.
Según las breves lecturas de muchas publicaciones en SO y algunos documentos UML, recopilo que hay 4 formas concretas principales de asociación de clases:
- composición: A está compuesta de A B; B no existe sin A, como una habitación en una casa
- agregación: A tiene-a B; B puede existir sin A, como un estudiante en un aula
- dependencia: A usa-a B; no hay dependencia del ciclo de vida entre A y B, como un parámetro de llamada de método, valor de retorno o un temporal creado durante una llamada de método
- generalización: A es-a B
Cuando una relación entre dos entidades no es una de estas, puede llamarse simplemente "una asociación" en el sentido genérico del término y describirse de otra forma (nota, estereotipo, etc.).
Mi conjetura es que la "asociación genérica" está destinada a usarse principalmente en dos circunstancias:
- cuando los detalles de una relación todavía están siendo resueltos; 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", por lo que no se queda atascado usando una relación incorrecta con una nota "esto no es realmente agregación, es solo eso UML no tiene ningún otro símbolo que podamos usar "
Es importante comprender por qué deberíamos siquiera molestarnos en usar más de una línea de relación. La razón más obvia es describir la relación entre padres e hijos entre las clases (cuando se eliminan todos los padres, como resultado, se eliminan), pero de manera más impotente, queremos distinguir entre asociación simple y composición para establecer 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 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 indica que existe algún tipo de enlace o dependencia entre dos clases o más.
Asociación débil
ClassA se puede vincular a ClassB para mostrar que uno de sus métodos incluye el parámetro de la instancia de ClassB o la instancia de ClassB.
Asociación fuerte
ClassA también se puede vincular a ClassB para mostrar que contiene una referencia a la instancia de ClassB.
Agregación (Asociación Compartida)
En los casos en que existe una relación de parte entre ClassA (entera) y ClassB (parte), podemos ser más específicos y usar el enlace de agregación en lugar del enlace de asociación, resaltando que ClassB también puede ser agregada 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 sea propietaria de ClassB ni que haya una relación padre-hijo (cuando el padre eliminó todos sus hijos se eliminan como resultado) entre los dos. En realidad, todo lo contrario! El enlace de agregación generalmente se usa para resaltar el hecho de que ClassA no es el contenedor exclusivo de ClassB, ya que, de hecho, ClassB tiene otro contenedor.
Aggregation vs Association 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 un / s método / s que contiene el parámetro ClassB pero ClassA no Mantener la referencia a la instancia de ClassB.
Martin Fowler sugiere que el enlace de agregación no debe usarse en absoluto porque no tiene un valor agregado y perturba la consistencia, citando a Jim Rumbaugh "Piense en ello como un placebo de modelo".
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 relación de parte entre ClassA y ClassB, existe una fuerte dependencia del ciclo de vida entre los dos, lo que significa que cuando se elimina ClassA, también se elimina ClassB.
El enlace de composición muestra que una clase (contenedor, entero) tiene propiedad exclusiva sobre otra (s) clase (s), 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 utiliza 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.
Medición de la complejidad del sistema.
La complejidad del sistema se puede medir simplemente observando 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 la clase B, entonces cualquier clase dada que use la clase A teóricamente puede verse afectada por los cambios en la clase B. La suma del número de clases potencialmente afectadas por cada clase en el sistema es la complejidad total del sistema.
Puedes leer más aquí: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html
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 .
Tenga en cuenta 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 principal problema es el malentendido generalizado y continuo (incluso entre desarrolladores de software expertos) 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 parte total con partes no compartibles donde las partes pueden desprenderse y sobrevivir a la destrucción del todo.
Por lo que puedo ver, esta confusión tiene dos raíces:
En la comunidad de C ++, el término "agregación" se usó en el sentido de una clase que define un atributo para hacer referencia a objetos de otra clase independiente (ver, por ejemplo, [1]), que es el sentido de asociación en los Diagramas de Clase UML. El término "composición" se usó para las clases que definen objetos componentes para sus objetos, de manera que en la destrucción del objeto compuesto, estos objetos componentes también se destruyen.
En los Diagramas de clases UML, tanto la "agregación" como la "composición" se han definido como casos especiales de asociaciones que representan relaciones parte-todo (que han sido discutidas en filosofía durante mucho tiempo). En sus definiciones, la distinción entre "agregación" y "composición" se basa en el hecho de que permite compartir una parte entre dos o más enteros. Definen "composiciones" como partes que no se pueden compartir (exclusivas), mientras que "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 entre la parte y el todo), no han logrado definirlos de 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 pueden tener estas relaciones, y los desarrolladores no están de acuerdo en cómo implementarlas.
Véase también mi respuesta extendida a la pregunta SO de abril de 2009 que se encuentra a continuación.
Y la propiedad que se asumió para definir la "composición" entre los objetos OOP en la comunidad C ++ (y esta creencia todavía 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 de la "composición" porque podemos tener tales dependencias debido a la integridad referencial también en otros tipos de asociaciones.
Por ejemplo, el siguiente patrón de código para "composición" se propuso 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 para 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 comunicarse con el 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 y agregación en
[ Apr 2009 ]
Agregación versus Composición [cerrado como basado principalmente en la opinión de]
[ Apr 2009 ]
¿Cuál es la diferencia entre composición y 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? [duplicar]
[ Octubre de 2009 ]
¿Cuál es la diferencia entre agregación, composición y dependencia? [marcado como duplicado]
[ Noviembre de 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)
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 una association . No se encuentran muy a menudo los términos composition y aggregation , al leer documentación o artículos, relacionados con ActiveRecord. Se crea una asociación agregando una de las macros de la clase de asociación al cuerpo de la clase. Algunas de estas macros son belongs_to , has_one , has_many , etc.
Si deseamos configurar una composition o aggregation , debemos agregar belongs_to al modelo propio (también denominado hijo) y has_one o has_many al modelo propietario (también llamado padre). Si configuramos la composition o la aggregation dependeremos de las opciones que belongs_to al belongs_to llamada en el modelo secundario. Antes de Rails 5, la configuración de belongs_to sin ninguna opción creaba una aggregation , el hijo podría existir sin un padre.Si queríamos una composition, necesitábamos declararla 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 hijo no puede existir sin un padre. Por lo tanto, el ejemplo anterior se puede reescribir como:
class Room < ApplicationRecord
belongs_to :house
end
Si queremos permitir que el objeto secundario exista sin un padre, debemos declararlo explícitamente a través de la opción optional
class Product < ApplicationRecord
belongs_to :category, optional: true
end
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 me siento más cómodo).
Cuando pensamos en la naturaleza orientada a objetos, siempre pensamos en objetos, clases (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 los 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 el objeto de composición de una clase, "posee" el objeto de otra clase .
- Pero hay una diferencia sutil. En Composición, el objeto de la clase que es propiedad del objeto de su clase propietaria no puede vivir por sí mismo (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 propiedad de la clase está muerto.
- Por lo tanto, en la composición si el objeto propietario se recolecta como basura, el objeto propio también será el 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 se puede usar en ningún otro automóvil). Este tipo de relación entre la clase Car y SpecificEngine se denomina Composición. El objeto de la clase Car no puede existir sin el objeto de la clase SpecificEngine y el objeto de SpecificEngine no tiene ningún significado sin la clase Car. Para poner en palabras simples, la clase Car solo "posee" la clase SpecificEngine.
Ejemplo de agregación : Ahora considere la clase Coche y la clase Rueda . El coche necesita un objeto de rueda para funcionar. Significado Objeto de automóvil Objeto de rueda propio, pero no podemos decir que el objeto de rueda no tenga ningún significado sin objeto de automóvil. Se puede utilizar muy bien en una bicicleta, camión u otro objeto de coches.
Resumiendo -
Para resumir, la asociación es un término muy genérico que se utiliza para representar cuando en clase se usan las funcionalidades proporcionadas por otra clase. Decimos que es una composición si un objeto de clase padre posee otro objeto de clase hijo y ese objeto de clase hijo no puede existir de manera significativa sin el objeto de clase padre. Si puede, entonces se llama Agregación.
Una relación entre dos objetos se conoce como una asociación .
Una asociación se conoce como composición cuando un objeto posee otro.
Mientras que una asociación se conoce como agregación cuando un objeto usa otro objeto.
Asociación
La asociación representa la relación entre dos clases. Puede ser unidireccional (una vía) o bidireccional (dos vías)
por ejemplo:
- unidireccional
El cliente hace pedidos
- bidireccional
A esta casado con B
B esta 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:
club tiene miembros
Un club ("todo") está formado por varios miembros del club ("partes"). Los miembros tienen vida fuera del club. Si el club ("todo") muriera, los miembros ("partes") no morirían con él. Porque el miembro puede pertenecer a múltiples clubes ("todo").
Composición
Esta es una forma más fuerte de agregación. "Todo" es responsable de la creación o destrucción de sus "partes".
Por ejemplo:
Una escuela tiene departamentos.
En este caso, la escuela ("entera") debía morir, el departamento ("partes") moriría con ella. Porque cada parte puede pertenecer a un solo "entero".
Composición (Si elimina "todo", "parte" también se elimina automáticamente - "Propiedad")
Crea objetos de tu clase existente dentro de la nueva clase. Esto se llama composición porque la nueva clase está compuesta por objetos de clases existentes.
Típicamente usa 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 "entero", puede existir "Parte" - "Sin propiedad")
Una agregación es un tipo específico de composición donde no se implica la propiedad entre el objeto complejo y los subobjetos. Cuando se destruye un agregado, los subobjetos no se destruyen.
Normalmente, se usan variables de puntero / variable 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 se responsabiliza 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 --------------------
Composición : Aquí es donde una vez que destruyes un objeto (Escuela), otro objeto (Aulas) que está vinculado a él también se destruiría. Ambos no pueden existir independientemente.
Agregación : esto es exactamente lo contrario de la asociación anterior ( Composition ) donde, una vez que se mata a un objeto ( Company ), el otro objeto ( Employees ) que está vinculado a él puede existir por sí solo.
Asociacion
Composición y agregación son las dos formas de asociación.
Dependencia (referencias)
Significa que no hay un vínculo conceptual entre dos objetos. por ejemplo, EnrollmentService hace referencia a objetos de Estudiante y Curso (como parámetros de método o tipos de devolución)
public class EnrollmentService {
public void enroll(Student s, Course c){}
}
Asociación (has-a)
Significa que casi siempre hay un enlace 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 entera)
Tipo especial de asociación donde existe una relación parcial entre dos objetos. Sin embargo, podrían vivir uno sin el otro.
public class PlayList{
private List<Song> songs;
}
Nota: la parte más complicada es distinguir la agregación de la asociación normal. Sinceramente, creo que esto está abierto a diferentes interpretaciones.
Composición (ha-a + parte entera + propiedad)
Tipo especial de agregación. Un Apartment se compone de algunas Room s. Una Room no 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();
}
}
La asociación es concepto generalizado de relaciones. Incluye composición y 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 gregació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 puede trabajar en más de un departamento, pero un departamento no puede formar parte de más de una universidad.
Para dos objetos, Foo y Bar se pueden definir las relaciones.
Asociación - Tengo una relación con un objeto. Foo usa la Bar
public class Foo {
void Baz(Bar bar) {
}
};
Composición - Soy dueño de un objeto y soy responsable de su vida útil, cuando Foo muere, también lo hace Bar
public class Foo {
private Bar bar = new Bar();
}
Agregación: tengo un objeto que tomé prestado de otra persona. Cuando Foo muere, Bar puede vivir.
public class Foo {
private Bar bar;
Foo(Bar bar) {
this.bar = bar;
}
}
en una oración muy simple: la agregación y la composición son subconjuntos de asociación. Un uso B -> esto es una agregación, A necesita B -> es composición. Lea más here .
La asociación es una relación donde todos los objetos tienen su propio ciclo de vida y no hay propietario.
Tomemos un ejemplo de profesor y alumno. Varios estudiantes pueden asociarse con un solo maestro y un solo estudiante puede asociarse con varios maestros, pero no hay propiedad entre los objetos y ambos tienen su propio ciclo de vida. Ambos se pueden crear y eliminar de forma independiente.
La agregación es una forma especializada de asociación donde todos los objetos tienen su propio ciclo de vida, pero hay propiedad y los objetos secundarios no pueden pertenecer a otro objeto principal.
Tomemos un ejemplo de departamento y maestro. Un solo profesor no puede pertenecer a varios departamentos, pero si eliminamos el departamento, el objeto del profesor no se destruirá. Podemos pensar en ello como una relación "tiene-a".
La composición es nuevamente una forma especializada de agregación y podemos llamarla como una relación de "muerte". Es un tipo fuerte de agregación. El objeto secundario no tiene su ciclo de vida y, si se elimina el objeto principal, también se eliminarán todos los objetos secundarios.
Tomemos nuevamente un ejemplo de relación entre la casa y las habitaciones. La casa puede contener varias habitaciones: no hay vida independiente de la habitación y cualquier habitación no puede pertenecer a dos casas diferentes. Si borramos la casa - la habitación se borrará automáticamente.
Tomemos otro ejemplo de relación entre Preguntas y Opciones. Las preguntas individuales pueden tener múltiples opciones y la opción no puede pertenecer a múltiples preguntas. Si eliminamos las preguntas, las opciones serán eliminadas automáticamente.