Was ist der Unterschied zwischen Assoziation, Aggregation und Komposition?

Question

Was ist der Unterschied zwischen Assoziation, Aggregation und Komposition? Erläutern Sie dies bitte anhand der Implementierung.

Answer 1

Wie schon gesagt, ist eine Assoziation eine Beziehung zwischen Objekten, Aggregation und Komposition sind Arten von Assoziationen.

Aus Sicht der Implementierung wird eine Aggregation dadurch erreicht, dass ein Klassenmitglied durch Verweis . Wenn zum Beispiel die Klasse A ein Objekt der Klasse B aggregiert, ergibt sich (in C++) folgendes Bild:

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

Die Semantik der Aggregation besteht darin, dass, wenn ein Objekt A zerstört wird, das Objekt B, das es speichert, weiterhin existiert. Bei der Komposition haben Sie eine stärkere Beziehung, in der Regel durch die Speicherung des Mitglieds nach Wert :

class A {
    B element;
};

Wenn ein A-Objekt zerstört wird, wird auch das B-Objekt, das es enthält, zerstört. Der einfachste Weg, dies zu erreichen, ist das Speichern des Elements als Wert, aber Sie könnten auch einen intelligenten Zeiger verwenden oder das Element im Destruktor löschen:

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

class A {
    B * element;

    ~A() {
        delete B;
    }
};

Wichtig ist, dass in einer Komposition das Container-Objekt besitzt das enthaltene, während es bei der Aggregation Referenzen es.

Answer 2

Es ist erstaunlich, wie viel Verwirrung über die Unterscheidung zwischen den drei Beziehungskonzepten herrscht Verein , Aggregation y Zusammensetzung .

Beachten Sie, dass die Begriffe Aggregation y Zusammensetzung wurden in der C++-Gemeinschaft verwendet, wahrscheinlich schon einige Zeit bevor sie als Spezialfälle von Verein in UML-Klassendiagrammen.

Das Hauptproblem ist das weit verbreitete und anhaltende Missverständnis (selbst unter erfahrenen Softwareentwicklern), dass das Konzept der Komposition eine Lebenszyklusabhängigkeit zwischen dem Ganzen und seinen Teilen impliziert, so dass die Teile nicht ohne das Ganze existieren können, wobei die Tatsache ignoriert wird, dass es auch Fälle von Teil-Ganzes-Assoziationen mit nicht gemeinsam nutzbaren Teilen gibt, bei denen die Teile vom Ganzen getrennt werden können und die Zerstörung des Ganzen überleben.

Soweit ich sehe, hat diese Verwirrung zwei Ursachen:

1. In der C++-Gemeinschaft wurde der Begriff "Aggregation" im Sinne einer Klasse verwendet, die ein Attribut zur Referenzierung von Objekten einer anderen unabhängigen Klasse definiert (siehe z. B. [1]), was dem Sinn von Verein in UML-Klassendiagrammen. Der Begriff "Komposition" wurde für Klassen verwendet, die Komponentenobjekte für ihre Objekte definieren, so dass bei Zerstörung des zusammengesetzten Objekts auch diese Komponentenobjekte zerstört werden.

2. In UML-Klassendiagrammen wurden sowohl "Aggregation" als auch "Komposition" als Spezialfälle von Assoziationen definiert, die Teil-Ganzes Beziehungen (die in der Philosophie schon seit langem diskutiert werden). In ihren Definitionen beruht die Unterscheidung zwischen einer "Aggregation" und einer "Komposition" auf der Tatsache, ob sie die gemeinsame Nutzung eines Teils durch zwei oder mehr Ganzheiten ermöglicht. Sie definieren "Kompositionen" als solche, deren Teile nicht geteilt werden können (exklusiv), während "Aggregate" ihre Teile teilen können. Darüber hinaus sagen sie etwas wie das Folgende: Sehr oft, aber nicht in allen Fällen, sind Zusammensetzungen mit einer Lebenszyklusabhängigkeit zwischen dem Ganzen und seinen Teilen verbunden, so dass die Teile nicht ohne das Ganze existieren können.

So hat die UML zwar die Begriffe "Aggregation" und "Komposition" in den richtigen Kontext (der Teil-Ganzes-Beziehungen) gestellt, aber es ist ihr nicht gelungen, sie klar und eindeutig zu definieren und die Intuitionen der Entwickler zu erfassen. Dies ist jedoch nicht überraschend, da es so viele verschiedene Eigenschaften (und Implementierungsnuancen) gibt, die diese Beziehungen haben können, und die Entwickler sind sich nicht einig, wie sie zu implementieren sind.

Siehe auch meine ausführliche Antwort zur unten aufgeführten SO-Frage vom April 2009.

Und die Eigenschaft, von der in der C++-Gemeinschaft angenommen wurde, dass sie die "Komposition" zwischen OOP-Objekten definiert (und diese Überzeugung ist immer noch weit verbreitet): die Laufzeit-Lebenszyklus-Abhängigkeit zwischen den beiden verwandten Objekten (dem Kompositum und seiner Komponente), ist nicht wirklich charakteristisch für die "Komposition", da wir solche Abhängigkeiten aufgrund der referenziellen Integrität auch in anderen Arten von Assoziationen haben können.

Zum Beispiel wurde das folgende Codemuster für "Komposition" vorgeschlagen in eine SO-Antwort :

final class Car {    
  private final Engine engine;

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

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

Der Befragte behauptete, dass es für die "Zusammensetzung" charakteristisch wäre, dass keine andere Klasse die Komponente referenzieren/kennen könnte. Dies trifft jedoch sicherlich nicht auf alle möglichen Fälle von "Zusammensetzung" zu. Insbesondere im Falle eines Automotors kann es sein, dass der Hersteller des Fahrzeugs, möglicherweise mit Hilfe einer anderen Klasse, auf den Motor verweisen muss, um den Eigentümer des Fahrzeugs kontaktieren zu können, wenn es ein Problem mit dem Motor gibt.

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

Anhang - Unvollständige Liste der wiederholt gestellten Fragen zu Komposition und Aggregation auf StackOverflow

[ Apr 2009 ]
Aggregation versus Komposition [als primär meinungsbasiert geschlossen von]
[ Apr 2009 ]
Was ist der Unterschied zwischen Zusammensetzung und Assoziationsbeziehung?
[ Mai 2009 ]
Unterschied zwischen Assoziation, Aggregation und Zusammensetzung
[ Mai 2009 ]
Was ist der Unterschied zwischen Zusammensetzung und Aggregation? [Duplikat]
[ Oktober 2009 ]
Was ist der Unterschied zwischen Aggregation, Komposition und Abhängigkeit? [als Duplikat markiert]
[ November 2010 ]
Assoziation vs. Aggregation [als Duplikat markiert]
[ August 2012 ]
Implementierungsunterschied zwischen Aggregation und Komposition in Java
[ Februar 2015 ]
UML - Assoziation oder Aggregation (einfache Codeschnipsel)

Answer 3

Verein

Assoziation stellt die Beziehung zwischen zwei Klassen dar, die unidirektional (einseitig) oder bidirektional (zweiseitig) sein kann.

zum Beispiel:

1. unidirektional

Kunde erteilt Aufträge

2. bidirektional

A ist mit B verheiratet

B ist mit A verheiratet

Aggregation

Aggregation ist eine Art von Assoziation, jedoch mit besonderen Merkmalen: Aggregation ist die Beziehung zwischen einer größeren "ganzen" Klasse und einer oder mehreren kleineren "Teil"-Klassen; umgekehrt ist eine kleinere "Teil"-Klasse ein Teil einer größeren "ganzen" Klasse.

zum Beispiel:

Club hat Mitglieder

Ein Verein ("Ganzes") besteht aus mehreren Vereinsmitgliedern ("Teilen"), die ein Leben außerhalb des Vereins haben. Wenn der Verein ("Ganzes") sterben würde, würden die Mitglieder ("Teile") nicht mit ihm sterben. Denn ein Mitglied kann mehreren Vereinen ("Ganzes") angehören.

Zusammensetzung

Dies ist eine stärkere Form der Aggregation: Das "Ganze" ist für die Entstehung oder Zerstörung seiner "Teile" verantwortlich.

Zum Beispiel:

Eine Schule hat Abteilungen

In diesem Fall würde die Schule ("Ganzes") sterben, die Abteilung ("Teile") würde mit ihr sterben. Denn jeder Teil kann nur zu einem "Ganzen" gehören.

Answer 4

Es ist wichtig zu verstehen, warum wir uns überhaupt die Mühe machen sollten, mehr als eine Beziehungslinie zu verwenden. Der naheliegendste Grund ist die Beschreibung der Eltern-Kind-Beziehung zwischen Klassen (wenn ein Elternteil gelöscht wird, werden auch alle seine Kinder gelöscht), aber noch wichtiger ist, dass wir zwischen einfacher Assoziation und Komposition unterscheiden wollen, um implizite Beschränkungen für die Sichtbarkeit und die Weitergabe von Änderungen an die verwandten Klassen festzulegen, was eine wichtige Rolle für das Verständnis von und Reduzierung Systemkomplexität.

Verein

Die abstrakteste Art, statische Beziehungen zwischen Klassen zu beschreiben, ist die Assoziationsverknüpfung, die einfach besagt, dass es eine Art von Verbindung oder Abhängigkeit zwischen zwei oder mehr Klassen gibt.

Schwache Assoziation

KlasseA kann mit KlasseB verknüpft werden, um zu zeigen, dass eine ihrer Methoden einen Parameter der KlasseB-Instanz enthält oder eine Instanz der KlasseB zurückgibt.

Starke Assoziation

KlasseA kann auch mit KlasseB verknüpft werden, um zu zeigen, dass sie einen Verweis auf eine KlasseB-Instanz enthält.

Aggregation (Gemeinsame Assoziation)

In Fällen, in denen eine Part-of-Beziehung zwischen KlasseA (ganz) und KlasseB (Teil) besteht, können wir spezifischer sein und den Aggregations-Link anstelle des Assoziations-Links verwenden, um hervorzuheben, dass KlasseB auch von anderen Klassen in der Anwendung aggregiert werden kann (daher wird Aggregation auch als gemeinsame Assoziation bezeichnet).

Es ist wichtig anzumerken, dass die Aggregationsverknüpfung in keiner Weise besagt, dass die Klasse A die Klasse B besitzt oder dass es eine Eltern-Kind-Beziehung zwischen den beiden gibt (wenn das Elternteil gelöscht wird, werden als Folge davon alle seine Kinder gelöscht). Das Gegenteil ist der Fall! Die Aggregationsverknüpfung wird in der Regel verwendet, um zu verdeutlichen, dass ClassA nicht der exklusive Container von ClassB ist, da ClassB in Wirklichkeit einen anderen Container hat.

Aggregation vs. Assoziation Die Assoziationsverknüpfung kann die Aggregationsverknüpfung in jeder Situation ersetzen, während die Aggregation die Assoziation nicht in Situationen ersetzen kann, in denen es nur eine "schwache Verknüpfung" zwischen den Klassen gibt, d. h. KlasseA hat Methode/n, die Parameter von KlasseB enthalten, aber KlasseA hat keinen Verweis auf KlasseB-Instanz.

Martin Fowler schlägt vor, den Aggregationslink überhaupt nicht zu verwenden, da er keinen Mehrwert bringt und die Konsistenz stört, und zitiert Jim Rumbaugh: "Betrachten Sie ihn als ein Modellierungs-Placebo".

Zusammensetzung (Nicht-geteilte Assoziation)

Wir sollten spezifischer sein und die Kompositionsverknüpfung in Fällen verwenden, in denen zusätzlich zu der Part-of-Beziehung zwischen KlasseA und KlasseB eine starke Lebenszyklusabhängigkeit zwischen den beiden besteht, d. h., wenn KlasseA gelöscht wird, wird als Folge davon auch KlasseB gelöscht

Die Kompositionsverknüpfung zeigt, dass eine Klasse (Container, Ganzes) exklusives Eigentum an anderen Klassen (Teilen) hat, was bedeutet, dass das Containerobjekt und seine Teile eine Eltern-Kind-Beziehung darstellen.

Im Gegensatz zu Assoziation und Aggregation kann bei der Kompositionsbeziehung die komponierte Klasse nicht als Rückgabetyp oder Parametertyp der zusammengesetzten Klasse erscheinen. Daher können sich Änderungen an der komponierten Klasse nicht auf den Rest des Systems auswirken. Folglich begrenzt die Verwendung der Komposition den Anstieg der Komplexität, wenn das System wächst.

Messung der Systemkomplexität

Die Systemkomplexität lässt sich einfach messen, indem man sich ein UML-Klassendiagramm ansieht und die Assoziations-, Aggregations- und Kompositionsbeziehungslinien auswertet. Die Komplexität lässt sich messen, indem man feststellt, wie viele Klassen von der Änderung einer bestimmten Klasse betroffen sein können. Wenn die Klasse A die Klasse B offenlegt, kann theoretisch jede Klasse, die die Klasse A verwendet, von Änderungen an der Klasse B betroffen sein. Die Summe der Anzahl der potenziell betroffenen Klassen für jede Klasse im System ist die gesamte Systemkomplexität.

In meinem Blog können Sie mehr darüber lesen: http://aviadezra.blogspot.com/2009/05/uml-association-aggregation-composition.html

---

Answer 5

Association , Aggregation , Composition sind etwa Hat eine Beziehung.

Aggregation y Composition sind Teilmengen von Association die die Beziehung genauer beschreiben

Aggregation - unabhängig Beziehung. Ein Objekt kann innerhalb einer Klasse über Konstruktor, Methode, Setter... übergeben und gespeichert werden.

Composition - abhängig Beziehung. Ein Objekt ist erstellt nach Eigentümerobjekt

*Assoziation ist eine Alternative zur Sybtypisierung