Asossziation, Aggregation, Komposition - wie wird es realisiert

Einen wunderschönen Samstagabend an die Programmiergemeinde,

Ich hab folgendes Frage/Problem zwecks Klassen bezüglich Asossziation, Aggregation und Komposition:

ich verstehe nicht ganz, wo bei der programmiertechnischen Umsetzung der Unterschied liegt bzw. zur Assoziation habe ich keinerlei Programmierbeispiele gefunde. Es ist mir lediglich bekannt, dass in der Basisklasse ein Objekt der Nebenklasse erstellt mit (bei der Aggregation und bei der Komposition??)

Ich hoffe, meine Frage ist verständlich.

Grüße,
c0ast

volkard

Ich schieb den Thread mal weiter, weil die dabei nicht entstehenden Erkenntnisse für andere Sprechen gleichermaßen interessant sind.

C++ Forumbot

Dieser Thread wurde von Moderator/in volkard aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Firefighter

http://de.wikipedia.org/wiki/Assoziation_(UML)

Eventuell solltest du dir das nochmal durchlesen. Fals doch noch Unklarheiten sind, kannst du ja nochmal fragen.

Die Unterschiede sind mir klar, und mir geht es NICHT um die Darstellung oder die Realisierung im UML, sondern in der Art der programmierung in C++ (weshalb ich die Frage eigentlich auch beim Thema C++ gepostet hatte). Daher komme ich bei wiki nicht weiter.

Ich will mein Problem einmal anders formulieren: Wenn ich den Programmiercode meiner Klasse habe, wie sehe ich dann, ob es sich um eine Assoziatiion, Aggregation oder Komposition handelt (wenn zwei Klassen in Beziehung stehen versteht sich)??

Grüße c0ast

Zeus

Evtl. schon mal daran gedacht, dass es keine technische Entsprechung gibst. Hättest du den Text gelesen, würde dir auffallen, dass dort steht, dass die Beziehungen Sonderfälle sind, in der Gewichtung der Stärke des Assoziationsende.

Möchte man nun ein Assoziationsende hervorheben oder die Bindung einer Assoziation verstärken, so stehen einem Aggregation und Komposition als Mittel zur Verfügung.

Zur Zeit fällt mir keine Möglichkeit ein, wie man diese Stärke in C++ ausdrücken sollte.

Am besten Mal ArgoUML mit C++ Module installieren und ausprobieren.

Warum sollte man das nicht in C++ ausdrücken können? Das nachfolgende ist nirgends als Gesetz festgeschrieben, aber man kann es sehrwohl als Anhaltspunkt nehmen:

// Komposition:
// 1. Variante über private Vererbung
class A : private B
{ ... };

// 2. Variante über ein Value-Member
class A
{
   B b;   // lässt sich auch nicht löschen und kann auch nicht vergessen werden zu instanzieren!
};

// Aggregation:
class A
{
   B &b;  // Referenz, muß von draussen kommen
};

// Assoziation:
class A
{
   B *b;   // Pointer, kann aber muß nicht auf ein Objekt verweisen
};

Wie gesagt, es gibt Möglichkeiten in C++ z.B. eine starke Bindung/Verweise abzubilden. Oder halt Kompositionen sind auch kein Problem, sogar einfacher darzustellen als in z.B. Java, wo es nur Referenzen gibt, die immer null sein können. Mit dem Value-Member oder private Vererbung kann man Komposition sehr schön in C++ darstellen.

theta

Komposition / Assoziation hat nichts mit Pointer/Ref. oder nicht zu tun, sondern mit der Verantwortlichkeit über die Lebensdauer der Objekte.

Simon

c0ast schrieb:

Es ist mir lediglich bekannt, dass in der Basisklasse ein Objekt der Nebenklasse erstellt mit (bei der Aggregation und bei der Komposition??)

UML:
ObjektA--ObjektB

=>

using namespace A;
*objA = &objB;
// or
using namespace B;
*objB = &objA;

Bashar

c0ast schrieb:

ich verstehe nicht ganz, wo bei der programmiertechnischen Umsetzung der Unterschied liegt bzw. zur Assoziation habe ich keinerlei Programmierbeispiele gefunde. Es ist mir lediglich bekannt, dass in der Basisklasse ein Objekt der Nebenklasse erstellt mit (bei der Aggregation und bei der Komposition??)

Das liegt daran, dass die UML das nicht festlegt, auch gar nicht festlegen will, wie das im Code auszusehen hat. Üblicherweise kommen Assoziationen in Analysemodellen vor, d.h. wenn man sich Gedanken darüber macht, wie das Problem überhaupt zu verstehen ist. Deshalb sind da auch beliebige Kardinalitäten, Navigationsrichtungen, Rollennamen usw. erlaubt. In einem Designmodell würde man dann schon mehr auf die Möglichkeiten, die objektorientierte Programmiersprachen normalerweise bieten, Rücksicht nehmen, und nur noch Beziehungen verwenden, die man auch implementieren kann.

Bulli schrieb:

// 2. Variante über ein Value-Member
class A
{
   B b;   // lässt sich auch nicht löschen und kann auch nicht vergessen werden zu instanzieren!
};

Wieso kann man hier nicht vergessen die Variable zu instanzieren? Hier wurde sie ja nur deklariert oder? Eine Instanz davon wird ja erst z.B. im Kontruktor A aufgerufen? Oder zählt dieses "B b" schon als Instanzierung?

Laut meines Schulunterrichts realisieren wir die Aggregation mit Zeigern...

CDing ding;//Komposition
CDing *ding = new CDing();//Aggregation

Gruß
N.