Einleitung
In der Welt der Programmierung verbringe ich viel Zeit damit, Gruppen, Blogbeiträge usw. von anderen Entwicklern zu lesen. Ein bestimmter Beitrag hat kürzlich meine Aufmerksamkeit erregt und eine Menge Antworten und gemischte Meinungen zu einer gestellten Frage hervorgerufen: “Was ist der Unterschied zwischen Komposition und Aggregation und wie würde ich es in meinen Programmen ausdrücken?”
Komposition
Wie wir wissen, gibt uns Vererbung eine “ist-ein” Beziehung. Um das Verständnis der Komposition zu erleichtern, können wir sagen, dass die Komposition uns eine “Teil-von” Beziehung gibt. Komposition wird in einem UML-Diagramm als gefüllter Diamant dargestellt (siehe Abbildung 1).
Wenn wir ein Auto modellieren würden, würde es Sinn machen zu sagen, dass ein Motor ein Teil eines Autos ist. Bei der Komposition wird die Lebensdauer des Teils (Motor) vom Ganzen (Auto) verwaltet, das heißt, wenn das Auto zerstört wird, wird auch der Motor zerstört. Wie drücken wir das in C# aus?
public class Engine { . . . }
public class Car {
Engine e = new Engine();
…….
}Wie Sie im obigen Beispielcode sehen können, verwaltet das Auto die Lebensdauer des Motors.
Aggregation
Wenn Vererbung uns “ist-ein” gibt und Komposition uns “Teil-von” gibt, könnte man argumentieren, dass Aggregation uns eine “hat-ein” Beziehung gibt. Bei der Aggregation wird die Lebensdauer des Teils nicht vom Ganzen verwaltet. Um dies klarer zu machen, benötigen wir ein Beispiel. In den letzten 12+ Monaten war ich an der Implementierung eines CRM-Systems beteiligt, daher werde ich einen Teil davon als Beispiel verwenden.
Das CRM-System verfügt über eine Kundendatenbank und eine separate Datenbank, die alle Adressen in einem geografischen Gebiet enthält. Aggregation würde in dieser Situation Sinn machen, da ein Kunde eine Adresse “hat”. Es würde keinen Sinn machen zu sagen, dass eine Adresse “teil-von” einem Kunden ist, weil sie es nicht ist. Betrachten Sie es folgendermaßen: Wenn der Kunde aufhört zu existieren, hört die Adresse dann auf zu existieren? Ich würde argumentieren, dass sie nicht aufhört zu existieren. Aggregation wird in einem UML-Diagramm als ungefüllter Diamant dargestellt (siehe Abbildung 2).
Wie drücken wir das Konzept der Aggregation in C# aus? Nun, es ist etwas anders als bei der Komposition. Betrachten Sie den folgenden Code:
public class Address { . . . }
public class Person {
private Address address;
public Person(Address address) {
this.address = address;
}
. . .
}Person würde dann wie folgt verwendet werden:
Address address = new Address();
Person person = new Person(address);oder
Person person = new Person(new Address());Wie Sie sehen können, verwaltet die Person nicht die Lebensdauer der Adresse. Wenn die Person zerstört wird, existiert die Adresse immer noch. Dieses Szenario passt ziemlich gut zur realen Welt.
Fazit
Wie ich am Anfang des Artikels sagte, handelt es sich hierbei um meine Interpretation von Komposition und Aggregation. Die Entscheidung, ob man Komposition oder Aggregation verwenden sollte, sollte nicht schwierig sein. Bei der Objektmodellierung sollte es lediglich eine Frage sein, ob es sich um einen “Teil-von” oder “hat-ein”-Beziehung handelt.
