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?

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

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

Dieses Posting wurde automatisch erzeugt.

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

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

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.

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

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

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.

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.

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>

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.

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

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

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

"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