Assoziation & Aggregation

777

Hi Ihr,

Wir haben in der Schule jetzt in C++ Assoziationen gemacht aber ich verstehe irgendwie nicht so den Unterschied zur Aggregation, die wir schon vor einigen Monaten gemacht haben.
Bei der Assoziation ging es bei uns darum, dass es beispielsweise möglich war das Formular an ein eigenes Objekt zu übergeben und innerhalb dieser Klasse auf Eigenschaften des Formulares zu zu greifen.
Ich kann mir jedoch genauso gut zwei eigene Klassen schreiben, diese Aggregieren und dann ebenfalls über die eine Eigenschaften der anderen ändern.
Kann mir eventuell jemand erklären, was genau der Unterschied ist?

cya
David

PS: Bei der Assoziation wird das Formular irgendwie an die andere Klasse übergeben und 'überschreibt' diese irgendwie.
Beziehungsweise ist es dann plötzlich möglich über zwei verschiedene Objekte, die Eigenschaften der selben Instanz zu verändern. Hat das eventuell etwas mit dem Unterschied zutun oder habe ich da was falsch verstanden?

akari

Hallo

Die Aggregation ist ein Spezialfall der Assoziation.
Außerdem solltest du vermeiden solche sehr allgemeinen Konzepte mit konkreten Implementierungen zu erläutern, zumindestens ich kann jedenfalls nicht wirklich nachvollziehen was du zum beispiel damit meinst

Bei der Assoziation wird das Formular irgendwie an die andere Klasse übergeben und 'überschreibt' diese irgendwie

bis bald
akari

C++ Forumbot

Dieser Thread wurde von Moderator/in akari aus dem Forum VCL/CLX (Borland C++ Builder) 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.

Artchi

Die ganzen Begriffe aus der UML (meistens macht man halt das ganze als UML-Diagramm) kann man meistens garnicht in einer Programmiersprache "darstellen". Denn die Programmiersprachen können diese Leistung mit ihrem Sprachumfang garnicht abdecken. Wenn man das ganze in C++ oder Java umsetzt, muß man meinstens das ganze in der Implementierung "abschwächen".

777

Okay ich gebe mal ein kleines Beispiel, was ich mir unter Assoziation vorstelle.
Ich möchte von Klasse zwei das Attribut 'a' in Klasse eins ändern.

CPP-Datei:

TForm1 *Form1;
zwei * two;
eins * one;
__fastcall TForm1::TForm1(TComponent* Owner)
        : TForm(Owner)
{
   two = new zwei;
   one = new eins;
   two->set_zwei(one);
   two->set_a(3);
}

Header-Datei:

class eins
{
   private:
      int a;
};
class zwei
{
   private:
      eins * zu;
   public:
      void set_zwei(eins* zw)
      {
         zu = zw;
      }
      void set_a(int aa)
      {
         zu->a = aa;
      }
};

Doch in dieser Zeile ist ein Fehler:

zu->a = aa;

cya
David

Gast++

777 schrieb:

Doch in dieser Zeile ist ein Fehler:
zu->a = aa;

1. Stimmt!
2. "42" oder "was war jetzt die Frage zu der Zeile"?

Grüsse

*this

finix

777 schrieb:

Kann mir eventuell jemand erklären, was genau der Unterschied ist?

Der Unterschied ist weniger der im Code zu finden als in der Modellierung:

Ein Auto hat 4 Räder -> Aggregation (Räder sind Teil des Autos)
Ein Auto weiß auf welcher Straße es gerade fährt -> Assoziation (Auto "kennt" die Straße)

Vielleicht einfach mal www.google.com/search?q=association+vs+aggregation, http://de.wikipedia.org/wiki/Assoziation_%28UML%29 o.ä. bemühen.

Gast++

finix schrieb:

777 schrieb:

Kann mir eventuell jemand erklären, was genau der Unterschied ist?

Der Unterschied ist weniger der im Code zu finden als in der Modellierung:

Ein Auto hat 4 Räder -> Aggregation (Räder sind Teil des Autos)
Ein Auto weiß auf welcher Straße es gerade fährt -> Assoziation (Auto "kennt" die Straße)

Vielleicht einfach mal www.google.com/search?q=association+vs+aggregation, http://de.wikipedia.org/wiki/Assoziation_%28UML%29 o.ä. bemühen.

Eine "reine" Assoziation (also keine Aggregation oder gar Komposition) entspricht imo einer Verwendung einer Klasseninstanz (oder Ref od. Ptr darauf)

- als formalem Parameter einer Methode
- als lokalem Ausdruck in einer Methode ("Variable" will nicht scheiben da z.B. auf Singletons sowas wie getInstance() möglich ist).

@finix:
Siehst Du noch eine andere Entsprechung unter C++ die sie nicht zur Aggrgation/Koposition spezialisiert?

Grüsse

*this

finix

Gast++ schrieb:

@finix:
Siehst Du noch eine andere Entsprechung unter C++ die sie nicht zur Aggrgation/Koposition spezialisiert?

Um, ja, mein voriges Beispiel.

Ich sehe die Formulierung "unter C++" eigentlich eher als problematisch an. Du hast im Modell Assoziationen, Aggregationen etc., und das wird dann, in welcher Form auch immer, in C++ umgesetzt.

Aber du kannst z.B. bei

struct foo
{
  bar* baz;
};

nicht hergehen und aus dieser Definition herleiten dass das jetzt eine Aggregation oder was auch immer ist. Könnte genauso gut eine stinknormale Assoziation sein, oder eine Komposition, oder auch gar nicht im Modell vorkommen sondern einfach nur ein Artefakt der Implementation sein.

Artchi

Deshalb habe ich oben schon gesagt, das man die UML nicht in C++ abbilden kann. C++ (und andere Sprachen) bieten garnicht den entsprechenden Sprachumfang an.

Gast++

finix schrieb:

Gast++ schrieb:

@finix:
Siehst Du noch eine andere Entsprechung unter C++ die sie nicht zur Aggrgation/Koposition spezialisiert?

Um, ja, mein voriges Beispiel.

"Auto kennt die Strasse"

// Car.hpp
#include "Street.hpp"
//...
class Car {
public: // or whatever visibility
    void drive(Street& street);
//...
}:
// resp
// Car.cpp
#include "Street.hpp"
//...
void Car::drive(void) {
    Street street;
    //...  
}

Oder wie sonst noch?

finix schrieb:

Ich sehe die Formulierung "unter C++" eigentlich eher als problematisch an.

Stimmt. Imo besser "Umsetzung mittels". Einverstanden?

finix schrieb:

Aber du kannst z.B. bei
struct foo
{
  bar* baz;
};

Das ist aber jetzt die Richtung Code Model.
Bei "Assoziation" et al sehe ich eher die Umsetzung Model Code als klärenswert an.

Grüsse

*this

finix

Artchi schrieb:

Deshalb habe ich oben schon gesagt, das man die UML nicht in C++ abbilden kann. C++ (und andere Sprachen) bieten garnicht den entsprechenden Sprachumfang an.

Natürlich kann man UML in C++ (und vielen anderen Sprachen) abbilden!? Man kann es nur im Allgemeinen schlecht umkehren.

finix

Gast++ schrieb:

Oder wie sonst noch?

Ich meinte eigentlich eher

class car
{
  street*  location;
};

Das ist eine normale Assoziation.

Gast++ schrieb:

finix schrieb:

Ich sehe die Formulierung "unter C++" eigentlich eher als problematisch an.

Stimmt. Imo besser "Umsetzung mittels". Einverstanden?

Perfekt

Gast++ schrieb:

Bei "Assoziation" et al sehe ich eher die Umsetzung Model Code als klärenswert an.

Naja, Assoziation läuft doch im Prinzip zumeist darauf hinaus ein bar* oder container<bar*> im foo zu haben. Aber das kann man natürlich implementieren wie man will - wenn von 100.000 foo in der Regel nur 4, 5 tatsächlich zu bar s in Beziehung stehen könnte man diese auch einfach "auslagern".

Eine Operation car::crash_into(tree) würde ich jetzt nicht als Assoziation zwischen car und tree sehen, und einen "lokalen Ausdruck in einer Methode" noch viel weniger. Das war nicht wirklich was ich mit "kennen" meinte.

Gast++

finix schrieb:

Ich meinte eigentlich eher
class car
{
  street*  location;
};
Das ist eine normale Assoziation.

Jein. Ich geb ja gerne zu dass ich PDFs hasse und insbesondere die von der OMG (Object Managemtn Group aka "Oh My God" aka "Our Metaspec Gospel"), aber dies ist imo eine Aggregation (UML "by reference"), also eine spezialisierte Assoziation.

finix schrieb:

Gast++ schrieb:

Bei "Assoziation" et al sehe ich eher die Umsetzung Model Code als klärenswert an.

Naja, Assoziation läuft doch im Prinzip zumeist darauf hinaus ein bar* oder container<bar*> im foo zu haben.

Dto; ich kenne das als Aggregation(UML "by reference")

Grüsse

*this

P.S.:

finix schrieb:

Eine Operation [c]car::crash_into(tree)

Ach was, sowas löst man mit einem Sentry

class Sentry {
public:
    Sentry(Tree* pTree) {
         delete pTree;
    }
};

class Car { 
public:
    void crash_into(Sentry s) {

    }
};

...und schon isser weg, der Baum.

Kennst Du den MS-Airback?

"Es hat sich ein Auffahrunfall ereignet! Airbag wirklich aufblasen?"
<Ja> <Nein> <Abbrechen>

finix

Gast++ schrieb:

Jein. Ich geb ja gerne zu dass ich PDFs hasse und insbesondere die von der OMG (Object Managemtn Group aka "Oh My God" aka "Our Metaspec Gospel"), aber dies ist imo eine Aggregation (UML "by reference"), also eine spezialisierte Assoziation.

Hmm, naja, ich bin kein UML-Spezialist, von daher könntest du ggf. recht haben. Gibt's da irgendwo ein Zitat zu?

Gast++ schrieb:

...und schon isser weg, der Baum.

Gast++

finix schrieb:

Hmm, naja, ich bin kein UML-Spezialist, von daher könntest du ggf. recht haben. Gibt's da irgendwo ein Zitat zu?

Zitate gibt's viele (z.B. könnten meine ehemaligen Kursteilnehemr mich zitieren) aber was bringt das?

Autoritativ wäre

- ein Statement der OMG
- ein Statement von Prof. Stroustrup

Die OMG begibt sich aber nicht in gerne in die Niederungen konkreter Programmiersprachen und von Prof. Stroustrup kenne ich nichts explizites zum Verhältnis C++/UML.

In den "Sekudaärpublikationen" zu den OMG Standards findet sich der Terminus "Whole/Part" Beziehung, z.B. hier

http://www-306.ibm.com/software/rational/uml/

in Document "Basics III" auf S. 9.

"Whole/Part" führt mittels C++ umgesetzt zu einer "Membervariable" ggf. in einem Container.
Und für komplexe Typen gilt dies auch umgekehrt.

Grüsse

*this

finix

Gast++ schrieb:

"Whole/Part" führt mittels C++ umgesetzt zu einer "Membervariable" ggf. in einem Container.
Und für komplexe Typen gilt dies auch umgekehrt.

Dem ersten Teil kann ich - im Allgemeinen, s.o. - zustimmen, aber wieso sollte dies auch umgekehrt gelten?

Wie würdest du denn Flight und Plane in C++ umsetzen, das Beispiel zur bidirektionalen (Standard-) Assoziation auf Seite 6?

Gast++

finix schrieb:

Gast++ schrieb:

"Whole/Part" führt mittels C++ umgesetzt zu einer "Membervariable" ggf. in einem Container.
Und für komplexe Typen gilt dies auch umgekehrt.

Dem ersten Teil kann ich - im Allgemeinen, s.o. - zustimmen, aber wieso sollte dies auch umgekehrt gelten?

Wenn "etwas" (die Membervaiable) in etwas anderem (der Klasse resp ihren Instanzen) enthalten ist ist es ein Teil.
Meine Einschränkung bezog sich auf PODs und Basistypen (std::string), die muss man nicht als Supplier einer Aggregation/Komposition modellieren; sondern nimmt sie einfach als "normale" Attribute auf.

finix schrieb:

Wie würdest du denn Flight und Plane in C++ umsetzen, das Beispiel zur bidirektionalen (Standard-) Assoziation auf Seite 6?

Was da zu sehen ist ist eine fachliche Modellierung; das sollte man nicht 1:1 abzubilden versuchen sondern mit einer weiteren Klasse zu einem Dreieck erweitern.

"CFlight" und "CPlane" kennen sich dann nicht mehr sondern z.B. "CSchedule" kennt beide und garantiert die Kardinalitäten.

Grüsse

*this

finix

Gast++ schrieb:

Was da zu sehen ist ist eine fachliche Modellierung; das sollte man nicht 1:1 abzubilden versuchen sondern mit einer weiteren Klasse zu einem Dreieck erweitern.

"CFlight" und "CPlane" kennen sich dann nicht mehr sondern z.B. "CSchedule" kennt beide und garantiert die Kardinalitäten.

"Sollte" und "versuchen" hören sich nicht direkt an wie "OMFG hat entschieden das muss so gemacht werden".

Btw, Ungarische Notation ist evil

Gast++

finix schrieb:

"Sollte" und "versuchen" hören sich nicht direkt an wie "OMFG hat entschieden das muss so gemacht werden".

Dazu brauch ich nicht die OMG; dazu reicht mir meine Logik und meine Erfahrung mit zyklischen Abhängigkeiten und Forward-Deklaratioenen.

Was würde Dir ein Statement der OMG bringen wenn Du's in der Programmiersprache nicht ohne weitgehende Zugeständnisse zu Lasten guten Progrmmierstils umsetzen könntest?

Grüsse

*this

Assoziation &amp; Aggregation

Assoziation & Aggregation