3. Aggregation und Komposition realisieren

Aggregation und Komposition realisieren

  • F

    So, ich habe das jetzt per Pointer umgesetzt bekommen:

    Erstmal die Klassen:

    class Person;

class Konto  
{  
  private:  
    int m_Betrag;  
  protected:  
  public:  
    void m_SetBetrag(const int& value);  
    int m_iGetBetrag(); 
    Person *pParentPerson; 
    Konto(Person *pPerson);
    ~Konto();
};

class Person   
{   
private:   
   std::vector<Konto> m_Konten;
public:  
   void AddKonto();  
};

    Konstruktor von Konto:

    Konto::Konto(Person *pPerson)
{
   pParentPerson=pPerson;
};

    Implementierung von dem Hinzufügen eines Kontos in Person.

    void Person::AddKonto()
{
   Konto value(this);
   m_Konten.push_back(value);	
}

    Jetzt funktionieren solche Späße tatsächlich.

    Person.m_Konten[0].pParentKonto->m_iGetBetrag();

    Klar brauche ich das in dem Fall nicht wirklich, aber einige Methoden der Klasse Konto müssen ja vielleicht auf Daten ihrer Person Zugriff erlangen.

    Mich würde jetzt doch noch sehr dieselbe Realisierung per Referenz oder Verbindungsklasse interessieren. Oder vielleicht noch eine einfachere Heransgehensweise, falls es diese gibt.

    Danke schonmal,

    Fingolfin

    0
  • O

    Viel kann man mit Referenzen auch nicht rausholen:

    class Konto
{
private:
    int m_Betrag;
    Person* m_Besitzer; // 1
public:
    explicit Konto(Person& Besitzer) // 2
    : m_Besitzer(&Besitzer)
    {
    }
    int GetBetrag() const; // 3
    void SetBetrag(int value);
    Person& Besitzer() const // 4
    {
        return *m_Besitzer;
    }
};

    1: m_Besitzer weiterhin als Zeiger, damit man Konten gegenseitig zuweisen kann (mit Referenzen wäre das nicht möglich, weil man Referenzen selbst auch nicht zuweisen kann; std::vector will aber zuweisbare Elemente).
    2: Konstruktor sollte explicit sein (siehe Buch oder Doku) und nimmt eine Referenz an (dadurch kann man kein Konto ohne Besitzer erstellen, weil es keine Nullreferenzen gibt).
    3: GetBetrag sollte auf jeden Fall const sein, siehe http://www.gotw.ca/gotw/006.htm.
    4: Nach außen hin bekommt man auch nur eine Referenz. Ob diese Funktion const sein sollte, hängt wohl vom Design ab... (?)

    0
  • F

    @operator void

    Vielen Dank für die Infos. Sieht so aus als bliebe ich da eher bei Pointern, die verstehe ich mittlerweile wenigstens 😉 .

    Interessieren würde mich dennoch die Assoziationsklasse von der Marc++us erzählt hat und inwiefern diese der "schönere" Weg wäre.

    Vielen Dank schonmal,

    Fingolfin

    0
  • O

    Bei Referenzen gibt es imho nicht viel zu verstehen - dafür hat man dann halt einen intuitiven Weg, "dieser Parameter darf nicht 0 sein"/"diese Funktion gibt nie 0 zurück" auszudrücken. Pointer dann halt nur, wo es sein muss.

    Das mit der Verbindungsklasse würde mich aber auch interessieren 🙂

    0
  • S

    operator void schrieb:

    Das mit der Verbindungsklasse würde mich aber auch interessieren 🙂

    schaut euch zB das MEDIATOR Pattern an. In "Pattern Hatching" ist das gut beschrieben. aber bei google gibts sicher auch genug treffer.

    0
  • M

    Das gab's schon, bevor der Begriff "Design Pattern" eingeführte wurde... ist ein normaler Trick, wie man eine Assoziationsklasse im Entwurf realisiert. Das gab's noch zu den Zeiten von ADT und ADO mit Modula2... steht auch in "UML 2 für Dummies", Kapitel 14.

    Mediator-Pattern ist in der Tat wohl der aktuelle Begriff dafür.

    0
  • F

    Danke schonmal, aber es wäre echt nett, wenn das mal jemand einfach an dem kleinen Konto-Person Beispiel quellcodeseitig zeigen könnte. Ich besitze keines der Bücher und per Google landet man dann doch eher bei wissenschaftlichem Material zu dem Thema.

    Das wäre sehr nett,

    Fingolfin

    0
  • F

    @operator void

    Ich habe das mit der Referenz mal ausprobiert, um die Wartezeit auf die Assoziationsklasse zu verkürzen 😉 und bin dabei auf ein Problem gestoßen.
    Ich ahbe alles so umgesetzt, wie du es gesagt hattest und meine bestehenden Funktionen (AddKonto usw.) nicht angerührt.

    Ich habe versucht folgendermaßen den Namen einer Person auszugeben:

    cout<<"\n"<<my_person.m_aKonten[0].Besitzer.m_strGetName();

    Wie gesagt ist das ein bissel blödes Beispiel, da das so in der Praxis selten benötigt wird, aber mich interessiert es dennoch. 🙂

    Ich erhalte folgenden Fehler:

    error: request for member `
m_strGetName' in `((&my_person) + 8)->std::vector<_Tp,
_Alloc>::operator[](unsigned int) [with _Tp = Konto, _Alloc =
std::allocator<Konto>](0)->Besitzer', which is of non-aggregate type `
<unknown type>'

    Scheint ja irgendwie am vector zu hängen. 😕

    Vielen Dank schonmal,

    Fingolfin

    0
  • O

    Besitzer**()**?

    0
  • S

    Marc++us schrieb:

    Das gab's schon, bevor der Begriff "Design Pattern" eingeführte wurde...

    natuerlich.
    Design Pattern sind ja keine neue Inovationen, sondern geben den techniken bestimmte Namen.

    Ich finde es praktisch. Man muss nicht ewig erklaeren was man assoziationsklasse und Zwischenstufe meint, sondern sagt einfach: google mal nach Mediator Pattern 🙂

    0
  • B

    <imho>
    Genau. Die Patterns sollen weniger Lösungsvorschläge für Designprobleme sein (auch wenn ich sie hauptsächlich so verwende und damit ganz sicher nicht der einzige bin), nach meinem Verständnis ist die Essenz der Design Patterns, Namen für gebräuchliche Praktiken zu finden, damit man darüber kommunizieren kann. Dahinter steckt die Theorie (oder der Wunsch?) dass sich Software aus solchen Mustern zusammensetzt, so dass man diese eigentlich nur alle identifizieren muss, und dann auf einer ganz anderen Ebene über Softwarekonstruktion sprechen kann.
    </imho>

    0
  • F

    operator void schrieb:

    Besitzer**()**?

    😃 Oh Mann, du hast natürlich recht. Das ist jetzt schon das zweite mal, daß ich Stunden mit dem Fehler verbringe. *sichselbstindenhinterntritt

    Eine Frage hätte ich dann doch noch (wie immer 🙂 )

    Vorher (also mit Pointern) habe ich das Hinzufügen eines Kontos zu der Person folgendermaßen geregelt:

    void Person::AddKonto() 
{ 
   Konto value(this); 
   m_Konten.push_back(value);     
}

    Wie erfolgt das denn jetzt bei den Referenzen? Ich erhalte auf die Art immer:

    error: no matching function for
call to `Konto::Konto(Person* const)'
candidates are:
Konto::Konto(const Konto&)
error:
Konto::Konto(Person&)

    Wobei mir der Candidates error gar nix sagt, schließlich habe ich den Konstruktor exakt aus operator voids beispiel übernommen. Der müßte doch wenigstens 'ne Person erwarten und kein Konto. 😕

    Vielen Dank schonmal,

    Fingolfin

    0
  • O

    (Oh, ich sollte mal besser lesen :))

    Du musst this dereferenzieren, weil this ein Pointer und keine Referenz ist (warum auch immer?!).

    Der andere Konstruktor ist der automatisch generierte Kopierkonstruktor (siehe Literatur deiner Wahl 😉 ).

    0
  • F

    @operator void

    Danke aber so ganz bekomme ich anscheinend nie alles hin, was ich versuche. Gibt es nicht ein Tutorial in dem alle Varianten einmal quellcodeseitig gezeigt werden. So wie Marc++us das aufgesclüsselt hat:

    Komposition, 1 Element      Objektinstanz
Komposition, 0..1 Elemente  Zeiger auf Objektinstanz, 0 wird durch NULL angezeigt
Komposition, n Elemente     Array aus Objektinstanzen
Komposition, 0..* Elemente  dyn. Array (vector<T>, list<T>) aus Objektinstanzen
Aggregation, 1 Element      Referenz auf Objektinstanz
Aggregation, 0..1 Elemente  Zeiger auf Objektinstanz, NULL zeigt 0 an
Aggregation, n Elemente     Array aus Zeigern auf Objektinstanzen
Aggregation, 0..* Elemente  dyn. Array (vector<T*>, list<T*>) aus Zeigern auf Objektinstanzen

    und dann vielleicht mit Beispiel? Ich habe eine ganze Weile nach sowas gesucht, bin aber leider nicht fündig geworden. 😞

    Sowas wäre auch mal ein guter Beitrag für die FAQ 😉

    Fingolfin

    0
  • ?

    Aggregation, 1 Element Referenz auf Objektinstanz

    Bitte ein kleines Beispiel. 😕

    0
  • ?

    ? bitte ?

    0
  • ?

    ??? gibt es wirklich keines?

    0
Anmelden zum Antworten