Wo liegt der Unterschied zw. Assoziation, Aggregation und Komposition?
-
Wenn ich so was habe:
class Person
{
Adresse* adr;
..}
Und dann sage: Person HAT EINE Adresse.
Ist das dann Aggregation?!
-
Ja.
-
Aggregation könnte man aber auch mit einer Reference lösen (was meiner Meinung nach das ganze deutlicher macht):
class Person { Adresse &adresse; };Hat den Vorteil, das man im Konstruktor von Person eine Adresse als Parameter erzwingen muß. "Enthalten" kann man durch einen Pointer nicht erzwingen, denn der kann auch Null sein... das passt eher zu "kennen" oder "nicht kennen".
Komposition kann man aber auch durch ein Ist-Implementiert-mit realiesieren:
class Person : private Adresse { };Aber gängiger ist wohl, wie schon von anderen gesagt, eine Membervariable.
-
Achja, hier mal ein Zitat aus dem "UML kurz &gut" Buch:
Oft herrscht Unstimmigkeit über die Frage, wann eine Komposition besser als eine Aggregation passt, und mancher ist der Ansicht, man solle die Komposiotion überhaupt niemals verwenden.
-
Wird dann Aggregation und Assoziation durch Zeiger implementiert. Aber es muss
doch ein Unterschied sein. Vielleicht liegt der Unterschied im Konstruktor?
-
Das was Du hast im Prinip nur eine Assoziation, oder genauer, man kann es nicht sagen.
Eine Assoziation ist die einfachste Form einer Beziehung. Sie bildet eine "Hat-Ein" Beziehung ab. Aggregation und Komposition sind "strengere" Assoziationen. Man sagt auch, sie bilden eine "Ganzes - Teile" Beziehung ab. Bei der Aggregation kann ein von Element mehrere anderen Klassen referenziert werden, bei einer Komposition nur von genau einer.
Folgendes Codeschnipsel wäre für eine Aggreation korrekt, für eine Komposition nicht erlaubt, da in diesem Fall Object noch von anderen Klassen referenziert werden könnte.
public void do(Object o){ }Gute Beschreibung zu Beziehungen in UML: http://en.wikipedia.org/wiki/Class_diagram
-
goldslawik schrieb:
Wird dann Aggregation und Assoziation durch Zeiger implementiert. Aber es muss
doch ein Unterschied sein. Vielleicht liegt der Unterschied im Konstruktor?Wie von mir bereits vorgeschlagen, kann man Aggregation in C++ durch Reference-Members darstellen. So mache ich das gerne, falls es interessiert:
Assoziation: Pointer-Member
Aggregation: Reference-Member
Komposition: Objekt-Member (alternativ vielleicht eine "ist imlementiert mit" Technik)
-
goldslawik schrieb:
Wird dann Aggregation und Assoziation durch Zeiger implementiert. Aber es muss
doch ein Unterschied sein. Vielleicht liegt der Unterschied im Konstruktor?UML hat nix mit C++ oder einer anderen Sprache zu tun. Das Ziel von UML ist es, Vorgänge und Klassenbeziehungen einfach zu modellieren. Die Modelle entstehen zu einer Phase, in der man noch kaum an eine mögliche Implementierung denkt. Bei großen Projekten werden die Softwaresysteme auch von anderen Personen modelliert/entworfen, als später programmiert.
Mit welchen Sprachmitteln Du etwas modellierst, bleibt Dir überlassen. Wichtig ist nur, dass Du sie korrekt programmierst.
-
Wichtig ist nur, dass Du sie korrekt programmierst.
Und genau das hat er gefragt. C++ ist auch nur eine Sprache, wie UML. Es bringt ja nichts, es in UML richtig zu machen, aber in C++ falsch zu "übersetzen". Denn umgekehrt würde es dann nämlich schief gehen.
Seine Frage ist also völlig legitim.
-
@Artchi: Uups, ich dachte es geht um die Unterschiede zwischen den verschiedenen Beziehungen. BTW: Die meisten "guten" Case-Tools erzeugen Code. Das ist nicht nur praktisch, sondern spart zudem viel Zeit und Nerven.
-
Nur das heutzutage keiner mehr UML benutzt ... außer auf der Uni ....
-
Das gilt vielleicht für Wald- und Wiesenprogrammierer. Wer seinen Job auch nur ein wenig ernstnimmt, macht sich vor der Implementierung seine Gedanken. Und da man auch eine geeignete Programmiersprache finden muß, ist Modellierung mittels UML eine geniale Lösung, da man sich noch nicht auf eine Sprache festlegen muß.
Außerdem kannst du mit der UML (besonders mit Use-Cases) auch dem letzten Kaufmann klarmachen, was du tun willst.