Was ist der Unterschied zwischen Assoziation, Aggregation und Zusammensetzung?

389

Was ist der Unterschied zwischen Assoziation, Aggregation und Zusammensetzung? Bitte erläutern Sie die Implementierung.

Standardgebietsschema
quelle
2
Dies mag für Anfänger etwas überwältigend sein, aber machen Sie einen kleinen Spaziergang durch die UML 2 Superstructure-Spezifikation: omg.org/docs/formal/09-02-02.pdf Abschnitt 7.3.3 für Association
Chickeninabiscuit
6
Ich sollte auch hinzufügen, dass es in UML 2 kein Element wie Aggregation oder Komposition gibt (es war jedoch in UML 1.4). In UML 2 werden Aggregation / Kompositionen als Zuordnungselemente implementiert, wobei die AggregationKind-Eigenschaft entweder auf Shared oder Composite festgelegt ist.
Chickeninabiscuit
Viele Antworten auf SO bereits: stackoverflow.com/search?q=aggregation+and+composition
lothar
2
nützlicher Artikel hier codeproject.com/Articles/22769/…
GibboK
6
Ich weiß, dass dies bereits viele Male beantwortet wurde, aber ich denke, die beste Erklärung, die ich jemals in dieser Angelegenheit gelesen habe, ist diese: holub.com/goodies/uml/#composition
WLin

Antworten:

385

Für zwei Objekte, Foound Barkönnen die Beziehungen definiert werden

Assoziation - Ich habe eine Beziehung zu einem Objekt. FooVerwendetBar

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

Komposition - Ich besitze ein Objekt und bin für dessen Lebensdauer verantwortlich. Wenn Foostirbt, stirbt auchBar

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

Aggregation - Ich habe ein Objekt, das ich von jemand anderem ausgeliehen habe. Wenn Foostirbt, Barkann weiterleben.

public class Foo { 
    private Bar bar; 
    Foo(Bar bar) { 
       this.bar = bar; 
    }
}
Jeff Foster
quelle
3
Scheint C # / Java-Code. In diesem Fall sind sowohl der Zuordnungs- als auch der Aggregationscode identisch. In beiden Fällen wird nur auf "Balken" verwiesen, und das BarObjekt kann weiterleben.
Ajay
@ Jeff Foster: Ich habe einige Zweifel. Wenn ich ein Balkenobjekt in Baz (Balkenleiste) instanziiere {bar = new Bar (); } im ersten Fall. Wird es noch Assoziation sein oder wird es jetzt Komposition?
Saket
21
@ Ajay: Die Aggregation behält die Referenz der Objekte bei, was bei der Zuordnung nicht der Fall ist. Daher der Unterschied in der Umsetzung.
ABCD
17
Die Assoziation ist etwas stärker als nur die Verwendung als Methodenparameter. Ich glaube, Ihr Assoziationscode-Snippet entspricht eher einer Abhängigkeitsbeziehung . Vielleicht möchten Sie Martin Fowler verwandten Artikel
Ahmad Abdelghany
5
@ AhmadAbdelghany ist korrekt. Das erste Beispiel ist eine Abhängigkeitsbeziehung. Der dritte arbeitet für die Assoziation und Aggregation.
André Valenti
122

Ich weiß, dass diese Frage als C # markiert ist, aber die Konzepte sind ziemlich allgemeine Fragen wie diese Weiterleitung hier. Also werde ich hier meinen Standpunkt darlegen (ein bisschen voreingenommen aus Java-Sicht, wo ich mich wohler fühle).

Wenn wir an objektorientierte Natur denken, denken wir immer an Objekte, Klassen (Objektpläne) und die Beziehung zwischen ihnen. Objekte sind miteinander verbunden und interagieren über Methoden miteinander. Mit anderen Worten, das Objekt einer Klasse kann Dienste / Methoden verwenden, die vom Objekt einer anderen Klasse bereitgestellt werden. Diese Art von Beziehung wird als Assoziation bezeichnet. .

Aggregation und Zusammensetzung sind Teilmengen der Assoziation, dh sie sind spezifische Assoziationsfälle.

Geben Sie hier die Bildbeschreibung ein

  • Sowohl in der Aggregation als auch in der Komposition "besitzt" das Objekt einer Klasse das Objekt einer anderen Klasse .
  • Aber es gibt einen subtilen Unterschied. In der Komposition kann das Objekt der Klasse, das dem Objekt der besitzenden Klasse gehört, nicht alleine leben (auch als "Todesbeziehung" bezeichnet). Es wird immer als Teil seines Besitzobjekts leben, wobei das abhängige Objekt wie in Aggregation eigenständig ist und existieren kann, selbst wenn das Objekt, das eine Klasse besitzt, tot ist.
  • Wenn also in der Komposition das besitzende Objekt durch Müll gesammelt wird, ist auch das besessene Objekt vorhanden, was bei der Aggregation nicht der Fall ist.

Verwirrt?

Zusammensetzungsbeispiel : Betrachten Sie das Beispiel eines Autos und eines Motors, die für dieses Auto sehr spezifisch sind (was bedeutet, dass es in keinem anderen Auto verwendet werden kann). Diese Art der Beziehung zwischen Car- und SpecificEngine- Klasse wird als Komposition bezeichnet. Ein Objekt der Car-Klasse kann ohne ein Objekt der SpecificEngine-Klasse nicht existieren, und ein Objekt der SpecificEngine hat ohne die Car-Klasse keine Bedeutung. Um es einfach auszudrücken: Die Car-Klasse "besitzt" ausschließlich die SpecificEngine-Klasse.

Aggregationsbeispiel : Betrachten Sie nun die Klasse Auto und die Klasse Rad . Das Auto braucht ein Radobjekt, um zu funktionieren. Das heißt, das Auto-Objekt besitzt das Rad-Objekt, aber wir können nicht sagen, dass das Rad-Objekt ohne das Auto-Objekt keine Bedeutung hat. Es kann sehr gut in einem Fahrrad, LKW oder einem anderen Autoobjekt verwendet werden.

Zusammenfassend -

Zusammenfassend ist Assoziation ein sehr allgemeiner Begriff, der verwendet wird, um darzustellen, wann eine Klasse die von einer anderen Klasse bereitgestellten Funktionen verwendet. Wir sagen, es ist Zusammensetzung, wenn ein übergeordnetes Klassenobjekt ein anderes untergeordnetes Klassenobjekt besitzt und dieses untergeordnete Klassenobjekt ohne das übergeordnete Klassenobjekt nicht sinnvoll existieren kann. Wenn es kann, heißt es Aggregation.

Weitere Details hier. Ich bin der Autor von http://opensourceforgeeks.blogspot.in und habe oben einen Link zum entsprechenden Beitrag hinzugefügt, um mehr Kontext zu erhalten.

Aniket Thakur
quelle
8
Ich wollte fragen, warum es Ihnen wichtig war, eine bereits beantwortete Frage zu beantworten, die vor mehr als 5 Jahren gestellt wurde, aber dann las ich Ihren Blogeintrag und er war viel informativer als einige der Antworten hier. Upvoted!
Donbhupi
2
Ich stimme @Donbhupi zu. Ihre Antwort ist viel informativer und korrekter als viele andere
zish
1
Es ist wirklich lustig, wenn C # - und Java-Entwickler behaupten, dass sie Komposition verwenden, wenn sie nur für primitive Typen mit diesen Sprachen vorhanden ist. Wenn Sie die Komposition wirklich verstehen wollen, müssen Sie C ++ verwenden, wo Objekte WIRKLICH Teil anderer Objekte sein können. Nicht nur im Heap-Speicher schweben und Zeiger aufeinander halten und behaupten, dass es Komposition gibt.
Jeder
@Jeder bin ich zu dem gleichen Schluss gekommen wie du, aber ich bin mir nicht so sicher. Angenommen, ich habe eine Klasse, die semantisch einer bestimmten Klasse gehört. Das besessene Objekt ist jedoch Garbage Collected, nachdem sein Eigentümer bereits vom Garbage Collector entfernt wurde. Wird es als Komposition betrachtet?
Paulo André Haacke
Können wir eine Komposition innerhalb von AC # -Code unter Verwendung des verwalteten Speichers haben?
Paulo André Haacke
85

Assoziation ist ein verallgemeinertes Konzept von Beziehungen. Es umfasst sowohl Zusammensetzung als auch Aggregation.

Komposition ( Mischung ) ist eine Möglichkeit, einfache Objekte oder Datentypen in eine Einheit zu packen . Kompositionen sind ein kritischer Baustein vieler grundlegender Datenstrukturen

Aggregation ( Sammlung ) unterscheidet sich von gewöhnlicher Zusammensetzung darin, dass sie kein Eigentum impliziert. Wenn in der Komposition das besitzende Objekt zerstört wird, sind es auch die enthaltenen Objekte. In der Aggregation ist dies nicht unbedingt wahr.

Beide bezeichnen die Beziehung zwischen Objekt und unterscheiden sich nur in ihrer Stärke.

Trick , den Unterschied zu erinnern: hat A - A ggregation und O wn - c O mpositoin

Geben Sie hier die Bildbeschreibung ein

Betrachten wir nun das folgende Bild

Beziehungen

Geben Sie hier die Bildbeschreibung ein

Analogie:

Komposition : Das folgende Bild ist eine Bildkomposition, dh es werden einzelne Bilder verwendet, um ein Bild zu erstellen.
Geben Sie hier die Bildbeschreibung ein

Aggregation : Sammlung von Bildern an einem Ort

Geben Sie hier die Bildbeschreibung ein

Zum Beispiel besitzt eine Universität verschiedene Abteilungen, und jede Abteilung hat eine Reihe von Professoren. Wenn die Universität schließt, werden die Abteilungen nicht mehr existieren, aber die Professoren in diesen Abteilungen werden weiterhin existieren. Daher kann eine Universität als eine Zusammensetzung von Abteilungen angesehen werden, während Abteilungen eine Ansammlung von Professoren haben. Darüber hinaus kann ein Professor in mehr als einer Abteilung arbeiten, eine Abteilung kann jedoch nicht Teil von mehr als einer Universität sein.

Premraj
quelle
14
Nachdem Sie so viel zu diesem Thema gelesen haben, ist diese Antwort die intuitivste und verständlichste. Sollte auf Wikipedia gestellt werden.
Jankapunkt
1
Schön artikuliert.
Sid
In Bezug auf die Aggregation sagen Sie "Untergeordnete Objekte gehören zu einem einzelnen übergeordneten Objekt". Das ist nicht richtig. Es ist eine gültige UML, eine gemeinsame Aggregation zu haben, dh ein Kind gehört mehreren Eltern. Sie erkennen dies in Ihrem Beispiel über die Abteilung als eine Ansammlung von Professoren an, weil Sie sagen, dass ein Professor für mehr als eine Abteilung arbeiten kann.
www.admiraalit.nl
@ www.admiraalit.nl AFAIK Shared Aggregation bedeutet nicht "ein Kind gehört mehreren Eltern", es ist nur umgekehrt, mehrere Kinder gehören denselben Eltern. Und es ist eine nicht zusammengesetzte Aggregation, denn selbst wenn die Eltern sterben, können die Kinder länger überleben.
Aderchox
65

Abhängigkeit (Referenzen)
Dies bedeutet, dass zwischen zwei Objekten keine konzeptionelle Verbindung besteht. zB EnrollmentService-Objektreferenzen Student & Course-Objekte (als Methodenparameter oder Rückgabetypen)

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

Assoziation (has-a)
Es bedeutet, dass fast immer eine Verbindung zwischen Objekten besteht (sie sind assoziiert). Das Bestellobjekt hat ein Kundenobjekt

public class Order {
    private Customer customer
}

Aggregation (hat einen + ganzen Teil)
Spezielle Art der Assoziation, bei der zwischen zwei Objekten eine ganzheitliche Beziehung besteht. Sie könnten jedoch ohne einander leben.

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

Hinweis: Der schwierigste Teil besteht darin, die Aggregation von der normalen Assoziation zu unterscheiden. Ehrlich gesagt denke ich, dass dies für unterschiedliche Interpretationen offen ist.

Zusammensetzung (hat einen + ganzen Teil + Besitz)
Besondere Art der Aggregation. An Apartmentbesteht aus einigen Rooms. A Roomkann nicht ohne existieren Apartment. Wenn eine Wohnung gelöscht wird, werden auch alle zugehörigen Räume gelöscht.

public class Apartment{
    private Room bedroom;
    public Apartment() {
       bedroom = new Room();
    }
}
Ahmad Abdelghany
quelle
1
Ja, der einzige schwierige Teil bei der Bestimmung von Objektbeziehungen besteht darin, zwischen Assoziation und Aggregation zu unterscheiden. Alles andere ist klar. +1 von mir
Fouad Boukredine
28

Aus einem Beitrag von Robert Martin in comp.object :

Die Zuordnung repräsentiert die Fähigkeit einer Instanz, eine Nachricht an eine andere Instanz zu senden. Dies wird normalerweise mit einem Zeiger oder einer Referenzinstanzvariablen implementiert, kann jedoch auch als Methodenargument oder zum Erstellen einer lokalen Variablen implementiert werden.

//[Example:]

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

class A
{
  private:
    B* itsB;
};

Aggregation [...] ist die typische Ganz / Teil-Beziehung. Dies ist genau das Gleiche wie eine Zuordnung mit der Ausnahme, dass Instanzen keine zyklischen Aggregationsbeziehungen haben können (dh ein Teil kann nicht sein Ganzes enthalten).

//[Example:]

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

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

Die Tatsache, dass dies eine Aggregation ist, bedeutet, dass die Instanzen des Knotens keinen Zyklus bilden können. Dies ist also ein Baum von Knoten, kein Diagramm von Knoten.

Die Zusammensetzung [...] ist genau wie die Aggregation, außer dass die Lebensdauer des "Teils" vom "Ganzen" gesteuert wird. Diese Steuerung kann direkt oder transitiv sein. Das heißt, das "Ganze" kann die direkte Verantwortung für das Erstellen oder Zerstören des "Teils" übernehmen, oder es kann ein bereits erstelltes Teil akzeptieren und es später an ein anderes Ganzes weitergeben, das die Verantwortung dafür übernimmt.

//[Example:]

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

class Car
{
  public:
    virtual ~Car() {delete itsCarb;}
  private:
    Carburetor* itsCarb
};
Pankaj Kolte
quelle
1
Wie viel Autorität hat diese Definition? Wird es von den UML-Standardautoren unterstützt? Ich es von Tools unterstützt?
Reinierpost
1
Es ist der Robert C. Martin. Das ist genug Autorität für mich :-)
Heliac
21

Wie andere sagten, ist eine Assoziation eine Beziehung zwischen Objekten, Aggregation und Zusammensetzung sind Arten von Assoziationen.

Aus Sicht der Implementierung wird eine Aggregation erhalten, indem ein Klassenmitglied als Referenz verwendet wird . Wenn Klasse A beispielsweise ein Objekt der Klasse B aggregiert, haben Sie ungefähr Folgendes (in C ++):

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

Die Semantik der Aggregation besteht darin, dass das zerstörte B-Objekt, wenn ein Objekt A zerstört wird, weiterhin vorhanden ist. Wenn Sie Komposition verwenden, haben Sie eine stärkere Beziehung, normalerweise indem Sie das Mitglied nach Wert speichern :

class A {
    B element;
};

Wenn ein A-Objekt zerstört wird, wird auch das darin enthaltene B-Objekt zerstört. Der einfachste Weg, dies zu erreichen, besteht darin, das Element nach Wert zu speichern. Sie können jedoch 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;
    }
};

Der wichtige Punkt ist, dass in einer Komposition das Containerobjekt das enthaltene besitzt , während es in der Aggregation darauf verweist .

Luc Touraille
quelle
8
Dies sollte die einzig akzeptierte Antwort sein. Komposition existiert in C # und Java nur bei primitiven Typen ... Sie sehen jedoch Entwickler dieser Sprachen, die Komposition "erklären". Zusammensetzung bedeutet, dass ein Objekt IN einem anderen existiert. In Java und C # können Sie es nicht einmal tun, alles ist auf dem Heap und Sie halten nur den Zeiger darauf, es ist wirklich Aggregation, nicht Komposition. C ++ bietet Komposition ..
Jeder
14

Es ist erstaunlich, wie viel Verwirrung über die Unterscheidung zwischen den drei Beziehungskonzepten Assoziation , Aggregation und Zusammensetzung besteht .

Beachten Sie, dass die Begriffe Aggregation und Zusammensetzung in der C ++ - Community wahrscheinlich einige Zeit verwendet wurden, bevor sie als spezielle Assoziationsfälle definiert wurden 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 ohne das Ganze nicht existieren können, wobei die Tatsache ignoriert wird, dass es auch solche gibt Fälle von Teil-Ganz-Assoziationen mit nicht teilbaren Teilen, bei denen die Teile vom Ganzen getrennt werden und die Zerstörung des Ganzen überleben können.

Soweit ich sehen kann, hat diese Verwirrung zwei Wurzeln:

  1. In der C ++ - Community wurde der Begriff "Aggregation" im Sinne einer Klasse verwendet, die ein Attribut zum Referenzieren von Objekten einer anderen unabhängigen Klasse definiert (siehe z. B. [1]). Dies ist der Assoziationssinn in UML-Klassendiagrammen. Der Begriff "Komposition" wurde für Klassen verwendet, die Komponentenobjekte für ihre Objekte definieren, sodass bei der Zerstörung des zusammengesetzten Objekts auch diese Komponentenobjekte zerstört werden.

  2. In UML-Klassendiagrammen wurden sowohl "Aggregation" als auch "Zusammensetzung" als Sonderfälle von Assoziationen definiert, die Teil-Ganz- Beziehungen darstellen (die in der Philosophie seit langem diskutiert werden). In ihren Definitionen basiert die Unterscheidung zwischen einer "Aggregation" und einer "Zusammensetzung" auf der Tatsache, dass es möglich ist, einen Teil zwischen zwei oder mehr Ganzen zu teilen. Sie definieren "Kompositionen" als nicht teilbare (exklusive) Teile, während "Aggregationen" ihre Teile teilen können. Darüber hinaus sagen sie etwa Folgendes: Sehr oft, aber nicht in allen Fällen, weisen Kompositionen eine Lebenszyklusabhängigkeit zwischen dem Ganzen und seinen Teilen auf, so dass die Teile ohne das Ganze nicht existieren können.

Während UML die Begriffe "Aggregation" und "Zusammensetzung" in den richtigen Kontext (von Teil-Ganz-Beziehungen) gestellt hat, ist es ihnen nicht gelungen, sie klar und eindeutig zu definieren und die Intuitionen der Entwickler zu erfassen. Dies ist jedoch nicht überraschend, da diese Beziehungen so viele verschiedene Eigenschaften (und Implementierungsnuancen) aufweisen können und die Entwickler sich nicht darüber einig sind, wie sie implementiert werden sollen.

Siehe auch meine erweiterte Antwort auf die unten aufgeführte SO-Frage vom April 2009.

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

Beispielsweise wurde das folgende Codemuster für "Zusammensetzung" in einer SO-Antwort vorgeschlagen :

final class Car {    
  private final Engine engine;

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

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

Der Befragte behauptete, es sei charakteristisch für "Zusammensetzung", dass keine andere Klasse auf die Komponente verweisen / sie kennen könne. Dies gilt jedoch sicherlich nicht für alle möglichen Fälle von "Komposition". Insbesondere im Fall eines Fahrzeugmotors muss der Hersteller des Fahrzeugs, möglicherweise mit Hilfe einer anderen Klasse implementiert, möglicherweise auf den Motor verweisen, um den Besitzer des Fahrzeugs kontaktieren zu können, wenn ein Problem damit auftritt.

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

Anhang - Unvollständige Liste wiederholt gestellter Fragen zu Zusammensetzung und Aggregation in StackOverflow

[ Apr 2009 ]
Aggregation versus Komposition [geschlossen als hauptsächlich meinungsbasiert von]
[ Apr 2009 ]
Was ist der Unterschied zwischen Komposition und Assoziationsbeziehung?
[ Mai 2009 ]
Unterschied zwischen Assoziation, Aggregation und Zusammensetzung
[ Mai 2009 ]
Was ist der Unterschied zwischen Zusammensetzung und Aggregation? [Duplikat]
[ Okt 2009 ]
Was ist der Unterschied zwischen Aggregation, Zusammensetzung und Abhängigkeit? [als Duplikat markiert]
[ Nov 2010 ]
Association vs. Aggregation [als Duplikat markiert]
[Aug 2012 ]
Implementierungsunterschied zwischen Aggregation und Komposition in Java
[ Feb 2015 ]
UML - Assoziation oder Aggregation (einfache Codefragmente)

Gerd Wagner
quelle
Upvote für die unvollständige Liste der wiederholt gestellten Fragen.
Jacco
13

Verband

Die Assoziation stellt die Beziehung zwischen zwei Klassen dar. Sie kann unidirektional (Einweg) oder bidirektional (Zweiweg) sein.

zum Beispiel:

  1. unidirektional

Kunde gibt Bestellungen auf

  1. bidirektional

A ist verheiratet mit B.

B ist verheiratet mit A.

Anhäufung

Aggregation ist eine Art Assoziation. Aber mit spezifischen Merkmalen. Aggregation ist die Beziehung in einer größeren "ganzen" Klasse, die eine oder mehrere kleinere "Teile" -Klassen enthält. Umgekehrt ist eine kleinere "Teil" -Klasse ein Teil der "ganzen" größeren Klasse .

zum Beispiel:

Club hat Mitglieder

Ein Club ("ganz") besteht aus mehreren Clubmitgliedern ("Teilen"). Mitglieder haben ein Leben außerhalb des Clubs. Wenn der Verein ("ganz") sterben würde, würden Mitglieder ("Teile") nicht damit sterben. Weil ein Mitglied mehreren Clubs angehören kann ("ganz").

Komposition

Dies ist eine stärkere Form der Aggregation. "Ganz" ist für die Schaffung oder Zerstörung seiner "Teile" verantwortlich.

Zum Beispiel:

Eine Schule hat Abteilungen

In diesem Fall würde die Schule ("ganz") sterben, die Abteilung ("Teile") würde damit sterben. Weil jeder Teil nur zu einem "Ganzen" gehören kann.

Dulaj Sanjaya
quelle
Im Falle einer Agregation. Sollte ich class Club(){ _member = new Member } es als Referenz verwenden oder weitergebenclass Club(){ addMember(Member member) { this._member = member } }
Rolle
12

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 Eltern alle Kinder gelöscht haben), aber ohnmächtiger möchten wir zwischen einfacher Zuordnung und Komposition unterscheiden, um implizite Einschränkungen für die Sichtbarkeit und die Sichtbarkeit festzulegen Weitergabe von Änderungen an die verwandten Klassen, eine Angelegenheit, die eine wichtige Rolle für das Verständnis und die Reduzierung der Systemkomplexität spielt.

Verband

Die abstrakteste Art, die statische Beziehung zwischen Klassen zu beschreiben, ist die Verwendung des Assoziationslinks, der lediglich angibt, dass zwischen zwei oder mehr Klassen eine Art Link oder eine Abhängigkeit besteht.

Schwache Assoziation

ClassA kann mit ClassB verknüpft sein, um zu zeigen, dass eine seiner Methoden Parameter der ClassB-Instanz enthält oder die Instanz von ClassB zurückgibt.

Starke Assoziation

ClassA kann auch mit ClassB verknüpft werden, um zu zeigen, dass es einen Verweis auf die ClassB-Instanz enthält.

Aggregation (Shared Association)

In Fällen, in denen ein Teil der Beziehung zwischen ClassA (ganz) und ClassB (part) besteht, können wir spezifischer sein und den Aggregationslink anstelle des Zuordnungslinks verwenden, um hervorzuheben, dass ClassB auch von anderen Klassen in der Anwendung aggregiert werden kann ( Daher wird Aggregation auch als Shared Association bezeichnet.

Geben Sie hier die Bildbeschreibung ein

Es ist wichtig zu beachten, dass der Aggregationslink in keiner Weise angibt, dass ClassA ClassB besitzt, und dass zwischen beiden eine Eltern-Kind-Beziehung besteht (wenn Eltern alle Kinder löschen, die als Ergebnis gelöscht werden). Im Gegenteil! Der Aggregationslink, der normalerweise verwendet wird, um den Punkt hervorzuheben, dass ClassA nicht der exklusive Container von ClassB ist, da ClassB tatsächlich einen anderen Container hat.

Aggregation gegen Assoziation Die Assoziationsverknüpfung kann die Aggregationsverknüpfung in jeder Situation ersetzen, während die Aggregation die Assoziation in Situationen nicht ersetzen kann, in denen nur eine 'schwache Verbindung' zwischen den Klassen besteht, dh ClassA verfügt über Methoden, die Parameter von ClassB enthalten, ClassA jedoch nicht Verweis auf ClassB-Instanz halten.

Martin Fowler schlägt vor, dass der Aggregationslink überhaupt nicht verwendet werden sollte, da er keinen Mehrwert hat und die Konsistenz stört. Jim Rumbaugh zitiert "Betrachten Sie ihn als ein Modellierungs-Placebo".

Zusammensetzung (nicht geteilte Assoziation)

Wir sollten spezifischer sein und den Kompositionslink in Fällen verwenden, in denen zusätzlich zu dem Teil der Beziehung zwischen ClassA und ClassB eine starke Lebenszyklusabhängigkeit zwischen beiden besteht, was bedeutet, dass beim Löschen von ClassA auch ClassB als Ergebnis gelöscht wird

Geben Sie hier die Bildbeschreibung ein

Der Kompositionslink zeigt, dass eine Klasse (Container, Ganzes) das ausschließliche Eigentum an anderen Klassen (Teilen) hat, was bedeutet, dass das Containerobjekt und seine Teile eine Eltern-Kind-Beziehung darstellen.

Im Gegensatz zu Zuordnung und Aggregation kann die zusammengesetzte Klasse bei Verwendung der Zusammensetzungsbeziehung nicht als Rückgabetyp oder Parametertyp der zusammengesetzten Klasse angezeigt werden. Änderungen an der zusammengesetzten Klasse können daher nicht auf den Rest des Systems übertragen werden. Folglich begrenzt die Verwendung der Zusammensetzung das Komplexitätswachstum, wenn das System wächst.

Systemkomplexität messen

Die Systemkomplexität kann einfach gemessen werden, indem ein UML-Klassendiagramm betrachtet und die Assoziations-, Aggregations- und Zusammensetzungsbeziehungslinien bewertet werden. Um die Komplexität zu messen, müssen Sie bestimmen, wie viele Klassen durch Ändern einer bestimmten Klasse betroffen sein können. Wenn Klasse A Klasse B verfügbar macht, kann jede Klasse, die Klasse A verwendet, theoretisch von Änderungen an Klasse B betroffen sein. Die Summe der Anzahl potenziell betroffener Klassen für jede Klasse im System ergibt die Gesamtsystemkomplexität.

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


Aviad Ezra
quelle
Gute Antwort. 1) Frage zum Kompositionsbeispiel: Leng und Hand (Kompositions-) Person. Wenn ich eine Klasse Tier und Schlaf erstelle, dann Schlaf (Agregation) Person; Schlaf (Agregation) Tier. Ist es richtig? 2). Handkomposition Person : class Person() { private hand = new Hand }. Schlafagregationsperson class Person() { private sleep = new Sleep }Ist der Schlüssel "neu" im Schlaf gültig? oder sollte ich es als Referenz übergeben, weil Agregation ist? class Person() { private Sleep _sleep; public addSleep(Sleep sleep) { this._sleep = sleep} }
Rolle
7

Zusammensetzung (Wenn Sie "Ganzes" entfernen, wird auch "Teil" automatisch entfernt - "Eigentum")

  • Erstellen Sie Objekte Ihrer vorhandenen Klasse in der neuen Klasse. Dies wird als Komposition bezeichnet, da die neue Klasse aus Objekten vorhandener Klassen besteht.

  • Verwenden Sie normalerweise normale Elementvariablen.

  • Kann Zeigerwerte verwenden, wenn die Kompositionsklasse die Zuordnung / Freigabe automatisch übernimmt, die für die Erstellung / Zerstörung von Unterklassen verantwortlich ist.

Geben Sie hier die Bildbeschreibung ein

Komposition in 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);
}

Ausgabe

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

Aggregation (Wenn Sie "Ganzes" entfernen, kann "Teil" existieren - "Kein Eigentum")

  • Eine Aggregation ist eine bestimmte Art von Komposition, bei der kein Besitz zwischen dem komplexen Objekt und den Unterobjekten impliziert ist. Wenn ein Aggregat zerstört wird, werden die Unterobjekte nicht zerstört.

  • Verwenden Sie normalerweise Zeigervariablen / Referenzvariablen, die auf ein Objekt verweisen, das außerhalb des Bereichs der Aggregatklasse liegt

  • Kann Referenzwerte verwenden, die auf ein Objekt verweisen, das außerhalb des Bereichs der Aggregatklasse liegt

  • Nicht verantwortlich für das Erstellen / Zerstören von Unterklassen

Geben Sie hier die Bildbeschreibung ein

Aggregationscode in 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);
}

Ausgabe

--------------- 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 --------------------
Saurabh Raoot
quelle
Wer diese Antwort abgelehnt hat. Können Sie bitte den Grund für die Ablehnung erklären?
Saurabh Raoot
Was mich wirklich verwirrt, ist, dass in vielen Fällen nicht der Eigentümer das Ding hält, sondern das, was er besitzt, den Besitzer "hält". Zum Beispiel hat das Auto keinen Zeiger vom Typ Motor *, aber die Klasse Motor hat ein Mitglied vom Typ Auto, um das Auto zu speichern, dem es gehört. Ich verstehe es nicht ganz, besonders die Uml-Beziehung der Klassen in diesem Fall.
Dudu
6

Das Problem mit diesen Antworten ist, dass sie die halbe Wahrheit sind: Sie erklären, dass Aggregation und Zusammensetzung Formen der Assoziation sind, aber sie sagen nicht, ob es möglich ist, dass eine Assoziation keine von diesen ist.

Ich stelle anhand einiger kurzer Lesungen vieler Beiträge zu SO und einiger UML-Dokumente fest, dass es vier konkrete Hauptformen der Klassenassoziation gibt:

  1. Zusammensetzung: A besteht aus einem B; B existiert nicht ohne A, wie ein Raum in einem Haus
  2. Aggregation: A hat-a B; B kann ohne A existieren, wie ein Schüler in einem Klassenzimmer
  3. Abhängigkeit: A verwendet-a B; Keine Lebenszyklusabhängigkeit zwischen A und B, wie z. B. ein Methodenaufrufparameter, ein Rückgabewert oder ein temporärer Wert, der während eines Methodenaufrufs erstellt wurde
  4. Verallgemeinerung: A ist-a B.

Wenn eine Beziehung zwischen zwei Entitäten keine davon ist, kann sie einfach als "Assoziation" im allgemeinen Sinne des Begriffs bezeichnet und auf andere Weise (Anmerkung, Stereotyp usw.) weiter beschrieben werden.

Ich vermute, dass die "generische Assoziation" hauptsächlich unter zwei Umständen verwendet werden soll:

  • wenn die Einzelheiten einer Beziehung noch ausgearbeitet werden; Eine solche Beziehung in einem Diagramm sollte so schnell wie möglich in das umgewandelt werden, was sie tatsächlich ist / sein wird (eine der anderen 4).
  • wenn eine Beziehung nicht mit einer der 4 von UML vorgegebenen übereinstimmt; Die "generische" Zuordnung bietet Ihnen immer noch die Möglichkeit, eine Beziehung darzustellen, die "nicht eine der anderen" ist, sodass Sie nicht in einer falschen Beziehung mit einer Notiz stecken bleiben. "Dies ist eigentlich keine Aggregation, sondern nur diese UML hat kein anderes Symbol, das wir verwenden könnten "
Oliver
quelle
1
Wie genau würden Sie eine generische Zuordnung implementieren, wenn alle anderen Optionen ausgeschlossen wären? Wenn A nicht aus B besteht (der Wert von B ist in A), ist A keine Aggregation von B (die Referenz von B ist nicht in A), B wird weder von A geerbt / realisiert, noch wird B als Rückgabe, Parameter oder innerhalb verwendet Funktionsnutzung von A, Sie haben so ziemlich keine Beziehung mehr.
Dean P
1
@DeanP Es kann vorerst nur generisch sein und wird später in eine der 4 konvertiert (dann wird es implementierbar); ODER es kann eine Beziehung sein, die nicht zu den 4 passt, wie zum Beispiel, dass Sie eine Assoziation wollen, die "sieht aus wie" bedeutet. Ohne eine generische Assoziation werden Sie gezwungen sein, eine der 4 zu verwenden, was den Leser irreführt, während wenn Sie verwenden generisch werden Sie es wahrscheinlich kommentieren oder eine Notiz einfügen, die erklärt, was es ist, und die meisten Leute lesen nur Notizen, wenn sie das Symbol nicht verstehen;)
Oliver
5

Ich denke, dieser Link wird Ihre Hausaufgaben machen: http://ootips.org/uml-hasa.html

Um die Begriffe zu verstehen, erinnere ich mich an ein Beispiel in meinen frühen Programmiertagen:

Wenn Sie ein 'Schachbrett'-Objekt haben, das' Box'-Objekte enthält, handelt es sich um Komposition denn wenn das 'Schachbrett' gelöscht wird, gibt es keinen Grund mehr, dass die Boxen existieren.

Wenn Sie ein "Quadrat" -Objekt mit einem "Farb" -Objekt haben und das Quadrat gelöscht wird, ist das "Farb" -Objekt möglicherweise noch vorhanden, dh Aggregation

Beide sind Assoziationen , der Hauptunterschied ist konzeptionell

Victor Hugo
quelle
5

Zusammensetzung : Hier wird, sobald Sie ein Objekt (Schule) zerstören, ein anderes Objekt (Klassenzimmer), das daran gebunden ist, ebenfalls zerstört. Beide können nicht unabhängig voneinander existieren.

Aggregation : Dies ist genau das Gegenteil der obigen ( Composition) Assoziation Company, bei der das andere Objekt ( Employees), das daran gebunden ist, für sich allein existieren kann, sobald Sie ein Objekt ( ) töten .

Verein .
Zusammensetzung und Aggregation sind die beiden Formen der Assoziation.

Kulasangar
quelle
1
Genau genommen können Mitarbeiter eines Unternehmens nicht ohne ein Unternehmen existieren. Es ist wahr, Sie töten die Menschen nicht, aber sie sind keine Angestellten dieser Firma mehr. Ich denke also, eine bessere Analogie wäre eine Niederlassung und Mitarbeiter, bei denen sie, selbst wenn die Niederlassung schließt, möglicherweise weiterhin Mitarbeiter des Unternehmens sind.
Alexander
1
Ja, absolut. Stimmen Sie zu ... +1 Vielen Dank an @AlexPopov für den Hinweis. :)
Kulasangar
4
    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.
Nouman Saleem
quelle
3

In einem sehr einfachen Satz:
Aggregation und Zusammensetzung sind Teilmengen der Assoziation.

  • A verwendet B -> dies ist eine Aggregation

  • A braucht B -> ist Komposition.

Lesen Sie hier mehr .

Alireza Rahmani Khalili
quelle
2

Ich möchte veranschaulichen, wie die drei Begriffe in Rails implementiert werden. ActiveRecord ruft jede Art von Beziehung zwischen zwei Modellen auf association. Man würde die Begriffe compositionund aggregationbeim Lesen von Dokumentationen oder Artikeln nicht sehr oft finden , die sich auf ActiveRecord beziehen. Eine Zuordnung wird erstellt, indem dem Hauptteil der Klasse eines der Zuordnungsklassenmakros hinzugefügt wird. Einige dieser Makros belongs_to, has_one, has_manyetc ..

Wenn wir ein compositionoder einrichten möchten aggregation, müssen wir belongs_todas eigene Modell (auch als untergeordnetes Modell bezeichnet) und / has_oneoder has_manydas besitzende Modell (auch als übergeordnetes Modell bezeichnet) hinzufügen . Ob wir einrichten compositionoder aggregationvon den Optionen abhängen, die wir belongs_toim untergeordneten Modell an den Anruf übergeben. Vor Rails 5 konnte das Kind ohne Eltern belongs_toerstellt werden aggregation, ohne dass Optionen erstellt wurden . Wenn wir eine wollten composition, mussten wir dies explizit deklarieren, indem wir die Option hinzufügten required: true:

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

In Rails 5 wurde dies geändert. Wenn Sie jetzt eine belongs_toZuordnung deklarieren, compositionwird standardmäßig ein Kind erstellt , das ohne ein Elternteil nicht existieren kann. Das obige Beispiel kann also wie folgt umgeschrieben werden:

class Room < ApplicationRecord
  belongs_to :house
end

Wenn wir zulassen möchten, dass das untergeordnete Objekt ohne übergeordnetes Objekt existiert, müssen wir dies explizit über die Option deklarieren optional

class Product < ApplicationRecord
  belongs_to :category, optional: true
end
Alexander
quelle
2

Aus: Remo H. Jansen Buch „Beginn der Reaktion: Lernen von TypeScript 2.x - Zweite Ausgabe“:

Wir nennen Assoziation jene Beziehungen, deren Objekte einen unabhängigen Lebenszyklus haben, in dem kein Eigentum an den Objekten besteht. Schauen wir uns ein Beispiel eines Lehrers und eines Schülers an. Mehrere Schüler können einem einzelnen Lehrer zugeordnet werden, und ein einzelner Schüler kann mehreren Lehrern zugeordnet werden, beide haben jedoch unabhängige Lebenszyklen (beide können unabhängig voneinander erstellt und gelöscht werden). Wenn ein Lehrer die Schule verlässt, müssen wir keine Schüler löschen, und wenn ein Schüler die Schule verlässt, müssen wir keine Lehrer löschen.

Wir nennen Aggregation jene Beziehungen, deren Objekte einen unabhängigen Lebenszyklus haben, aber Eigentümer sind und untergeordnete Objekte nicht zu einem anderen übergeordneten Objekt gehören können. Nehmen wir ein Beispiel für ein Mobiltelefon und einen Mobiltelefonakku. Ein einzelner Akku kann zu einem Telefon gehören. Wenn das Telefon jedoch nicht mehr funktioniert und wir es aus unserer Datenbank löschen, wird der Akku des Telefons nicht gelöscht, da er möglicherweise noch funktionsfähig ist. In der Aggregation haben Objekte also ihren Lebenszyklus, während es Eigentum gibt

Wir verwenden den Begriff Komposition , um Beziehungen zu bezeichnen, deren Objekte keinen unabhängigen Lebenszyklus haben. Wenn das übergeordnete Objekt gelöscht wird, werden auch alle untergeordneten Objekte gelöscht. Nehmen wir ein Beispiel für die Beziehung zwischen Fragen und Antworten. Einzelne Fragen können mehrere Antworten haben, und Antworten können nicht zu mehreren Fragen gehören. Wenn wir Fragen löschen, werden Antworten automatisch gelöscht.

HS Progr
quelle
1

Assoziation ist eine Beziehung zwischen zwei getrennten Klassen, und die Assoziation kann von einem beliebigen Typ sein, z. B. eins zu eins, eins zu Mai usw. Sie verbindet zwei völlig getrennte Einheiten.

Aggregation ist eine spezielle Form der Assoziation, bei der es sich um eine unidirektionale Einwegbeziehung zwischen Klassen (oder Entitäten) handelt, z. B. Wallet- und Money-Klassen. Brieftasche hat Geld, aber Geld muss nicht unbedingt Brieftasche haben, also ist es eine einseitige Beziehung. In dieser Beziehung können beide Einträge überleben, wenn der andere endet. In unserem Beispiel bedeutet dies nicht, dass die Money-Klasse nicht existieren kann, wenn die Wallet-Klasse nicht vorhanden ist.

Die Zusammensetzung ist eine eingeschränkte Form der Aggregation, bei der zwei Entitäten (oder man kann sagen Klassen) stark voneinander abhängig sind. Für zB Mensch und Herz. Ein Mensch braucht Herz zum Leben und ein Herz braucht einen menschlichen Körper zum Überleben. Mit anderen Worten, wenn die Klassen (Entitäten) voneinander abhängig sind und ihre Lebensdauer gleich ist (wenn eine stirbt, dann auch eine andere), dann ist es eine Zusammensetzung. Herzklasse hat keinen Sinn, wenn die menschliche Klasse nicht vorhanden ist.

Matloob Hasnain
quelle
1

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

Zusammensetzung: ist ein "Teil" der Beziehung.

Zum Beispiel "Motor ist Teil des Autos", "Herz ist Teil des Körpers".

Geben Sie hier die Bildbeschreibung ein

Assoziation: ist eine Beziehung vom Typ "hat-a"

Nehmen wir zum Beispiel an, wir haben zwei Klassen, dann werden diese beiden Klassen als "has-a" -Beziehungen bezeichnet, wenn beide Entitäten für eine Arbeit das Objekt des anderen teilen und gleichzeitig ohne gegenseitige Abhängigkeit existieren können oder beide ihre haben eigenes Leben.

Geben Sie hier die Bildbeschreibung ein

Das obige Beispiel zeigt eine Zuordnungsbeziehung, da sowohl die Employee- als auch die Manager-Klasse das Objekt voneinander und beide ihren eigenen unabhängigen Lebenszyklus verwenden.

Aggregation: basiert auf einer "has-a" -Beziehung und ist eine spezielle Form der Assoziation

Zum Beispiel "Student" und "Adresse". Jeder Schüler muss eine Adresse haben, damit die Beziehung zwischen der Schülerklasse und der Adressklasse vom Typ "Has-A" ist, aber umgekehrt ist dies nicht der Fall.

Geben Sie hier die Bildbeschreibung ein

TheGeeky
quelle