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

Zusammensetzung (Wenn Sie "ganz" entfernen, wird automatisch auch "Teil" entfernt - "Eigentümerschaft")

• Erstellen Sie Objekte Ihrer bestehenden Klasse innerhalb der neuen Klasse. Dies wird als Komposition bezeichnet, da die neue Klasse aus Objekten bestehender Klassen zusammengesetzt ist.

• Normalerweise werden normale Mitgliedsvariablen verwendet.

• Es können Zeigerwerte verwendet werden, wenn die Kompositionsklasse automatisch die Zuweisung/Deallokation übernimmt, die für die Erstellung/Destruktion von Unterklassen verantwortlich ist.

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 besondere Art der Komposition, bei der keine Eigentumsverhältnisse zwischen dem komplexen Objekt und den Unterobjekten bestehen. Wenn ein Aggregat zerstört wird, werden die Unterobjekte nicht zerstört.

• Typischerweise werden Zeigervariablen/Referenzvariablen verwendet, 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 Anwendungsbereichs der Aggregatklasse liegt

• Nicht verantwortlich für die Erstellung/Destruktion von Unterklassen

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

Answer 2

Das Problem mit diesen Antworten ist, dass sie nur die halbe Wahrheit sagen: Sie erklären, dass Aggregation und Komposition Formen der Assoziation sind, aber sie sagen nicht, ob es möglich ist, dass eine Assoziation weder das eine noch das andere ist.

Nach kurzer Lektüre vieler Beiträge auf SO und einiger UML-Dokumente gehe ich davon aus, dass es 4 konkrete Hauptformen der Klassenassoziation gibt:

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

Handelt es sich bei einer Beziehung zwischen zwei Entitäten nicht um eine dieser Beziehungen, kann sie einfach als "Assoziation" im allgemeinen Sinne des Begriffs bezeichnet und auf andere Weise weiter beschrieben werden (Anmerkung, Stereotyp usw.).

Ich vermute, dass die "generische Assoziation" vor allem in zwei Fällen verwendet werden soll:

• wenn die Einzelheiten einer Beziehung noch ausgearbeitet werden; eine solche Beziehung in einem Diagramm sollte so bald wie möglich in das umgewandelt werden, was sie tatsächlich ist/wird (eine der anderen 4).
• wenn eine Beziehung keiner der 4 von der UML vorgegebenen Beziehungen entspricht; die "generische" Assoziation gibt Ihnen immer noch die Möglichkeit, eine Beziehung darzustellen, die "nicht zu den anderen gehört", so dass Sie nicht eine falsche Beziehung mit dem Hinweis "dies ist eigentlich keine Aggregation, sondern nur ein Symbol, das die UML nicht kennt" verwenden müssen

Answer 3

In einem sehr einfachen Satz:
Aggregation und Komposition sind Untergruppen der Assoziation.

• A verwendet B -> dies ist eine Aggregation

• A braucht B -> ist Zusammensetzung.

Mehr lesen aquí .

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

Answer 5

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

Zusammensetzung: ist eine "part-of"-Beziehung.

zum Beispiel "der Motor ist Teil des Autos", "das Herz ist Teil des Körpers".

Vereinigung: ist eine Beziehung vom Typ "hat-a".

Nehmen wir zum Beispiel an, dass wir zwei Klassen haben, dann sagt man, dass diese beiden Klassen eine "has-a"-Beziehung haben, wenn beide Entitäten das Objekt des anderen für irgendeine Arbeit teilen und gleichzeitig ohne die Abhängigkeit des anderen existieren können oder beide ihre eigene Lebensdauer haben.

Das obige Beispiel zeigt eine Assoziationsbeziehung, da sowohl die Klasse Employee als auch die Klasse Manager das Objekt des jeweils anderen verwenden und beide ihren eigenen unabhängigen Lebenszyklus haben.

Aggregation: basiert auf einer "hat-a"-Beziehung und ist \\a besondere Form der Vereinigung

zum Beispiel "Student" und "Adresse". Jeder Schüler muss eine Adresse haben, so dass die Beziehung zwischen der Klasse "Schüler" und der Klasse "Adresse" eine Beziehung vom Typ "Hat-A" ist, aber umgekehrt gilt dies nicht.