Komposition, Aggregation,... in C++

hi, gibt es bei UML nur diese beziehungen zw klassen: Assoziation, Aggregation, Komposition, Vererbung? wo hängt die Generalisierung mit bei?

ist das nun komposition in C++:

class foo
{
};

class base
{
  private:
         foo m_foo;
};

cu

Artchi

Also Komposition heißt ja, das man etwas "zusammenbaut" und es ja somit ein fester Bestandteil sein _muß_. Ein Pointer wäre also nicht richtig, da dieser null sein kann. Im Scott Meyers Buch wurde das mal beschrieben, ich hab es leider verliehen, kann da also nicht mehr nachschlagen. Aber es gab zwei Varianten:

class A {
private:
    B b;
};

class A : private B {
};

Scott Meyers hatte auch beschrieben, wann welche Variante eher zum Einsatz kommen sollte. Vielleicht hat ja hier jemand das Buch griffbereit und kann mal nachschlagen?

Aggregation und Beziehungen würde man dann aber mit Pointer darstellen, da Aggregation auch ohne das Ganze existieren kann und somit null sein kann:

class A
{
private:
   B *b; // kann nämlich auch null sein
};

Das ist so mein Kenntnisstand.

hi,
welches buch war das von Scott Meyers?
kannst du zu Assoziation, Aggregation auch noch ein beispiel zeigen?

cu

net 0

assoziation ist sowas

class Futter
{
  ...
};

class Katze
{
  ...
  void fressen (Futter *f)
  {
     ...
  }
  ...
};

evilissimo

net schrieb:

assoziation ist sowas

class Futter
{
  ...
};

class Katze
{
  ...
  void fressen (Futter *f)
  {
     ...
  }
  ...
};

Assoziation ist eine Ist-Beziehung. Oder ist die Katze Futter?

Dein Beispiel ist eher eine Aggregation.

volkard

UML läßt sich nicht verlustfrei in c++ umsetzen.

net 0

evilissimo schrieb:

Assoziation ist eine Ist-Beziehung. Oder ist die Katze Futter?

die katze isst äääh frisst zwar futter, aber assoziation heisst einfach nur, dass die objekte eine beziehung haben. die richtung ist noch wichtig. guckst du: http://www.computerbase.de/lexikon/Assoziation_(UML2)

evilissimo

ich bin Ich hab da irgendwie was falsches im Kopf.

Aber das liegt daran das ich auch gar nicht wüsste was ich damit anfangen soll, ich benutzt das wissen eigentlich nie. Ich frag mich was einem das bringen soll.

Man kann sich vielleicht auf zeichen welche klassen man hat und welche Klasse welche Klasse benutzt. Aber im endeffekt ist es egal wie das heißt :p ( Dieses Statement soll nur von meiner Unwissenheit ablenken )

MfG

net 0

evilissimo schrieb:

Aber das liegt daran das ich auch gar nicht wüsste was ich damit anfangen soll, ich benutzt das wissen eigentlich nie. Ich frag mich was einem das bringen soll.

man kann z.b. am pc uml malen und dann mit rhapsody, rational rose, visual uml usw. daraus source code generieren. ersteres kann sogar puren c-code (ohne ++) erzeugen.

evilissimo

net schrieb:

evilissimo schrieb:

Aber das liegt daran das ich auch gar nicht wüsste was ich damit anfangen soll, ich benutzt das wissen eigentlich nie. Ich frag mich was einem das bringen soll.

man kann z.b. am pc uml malen und dann mit rhapsody, rational rose, visual uml usw. daraus source code generieren. ersteres kann sogar puren c-code (ohne ++) erzeugen.

Ich brauch keine Codegeneratoren, ich kann selber schreiben. In der Zeit in der ich mir die Mühe gemacht hab die ganzen Details in den UML Editor einzugeben hab ich das ganze schon selbst geschrieben...

Aber das ist Ansichtssache, ausserdem hab ich keine Lust für so etwas imho unnützes Geld auszugeben

MfG

net 0

evilissimo schrieb:

Ich brauch keine Codegeneratoren, ich kann selber schreiben. In der Zeit in der ich mir die Mühe gemacht hab die ganzen Details in den UML Editor einzugeben hab ich das ganze schon selbst geschrieben...

diese tools können's auch andersrum: aus source codes uml erzeugen. da kannste dann nach belieben am quelltext und/oder den uml-diagrammen rumschrauben. das schimpft sich 'round trip engineering'

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.

hi,
tja so ne genaue unterscheidung gibt es also nicht, kommt mir vor...

wo ist eine Generalisierung bzw Realisierung ein zu ordnen? kann ich ne abstrakte klasse, was ja ne art schnittstelle darstellt als Assoziation in UML modellieren?

ps.: bei der hitze kann man ja nicht mal nachdenken um die zeit

cu

Artchi

Volkard hat schon recht, wenn er sagt, das man UMLs nicht in C++ abbilden kann (auch in Java nicht, da sogar noch weniger!). Aber trotzdem kann man einiges doch abbilden.

Weiterhin dient so ein UML diagramm doch nur der fachlichen Dokumentation und nicht der technischen Doku. In unseren Projekten machen wir UMLs nie der technischen Umsetzung wegen, sondern dem fachlichen Wissen.

Das man dann UMLs für die technische Umsetzung nimmt, ist dann halt ein Gimmik. Nichts desto trotz wird in Scott Meyers "Effektiv C++ Programmieren" das Thema Komposition behandelt. Ich hab auch noch mal in das "Die C++ Programmiersprache" von Bjarne geschaut. Da sind mehrere Seiten drin die das Thema Assoziation u.ä. behandeln und wie man es entsprechend in C++ designed. Schaut mal in der 4. Auflage ab Kapitel 24.3.3 bis einschliesslich 24.3.6.

Achja, dabei sehe ich in Kapitel 24.3.6 noch folgendes Statement von Bjarne, das hier in dieses Topic reinpasst:

Eine Programmiersprache kann (und sollte) nicht jedes Konzept jeder Designmethode direkt unterstützen. ... Eine Designsprache sollte reichhaltiger sein und sich weniger um Details kümmern, als dies eine Sprache zur Systemprogrammierung tun muß.

Yo, also UML ist ja eine Designsprache und somit sollte man sich als C++ Programmierer nicht wundern, das es nicht 100% alle Möglichkeiten der Abbildung gibt. Was aber natürlich nicht ein paar Grundregeln ausschliesst.

Wie gesagt, Aggregation würde ich mit nem Pointer als Member darstellen. Assoziation über eine Methode die einen Pointer annimmt (dadurch gibt es eine Beziehung ("Kontakt") zwischen zwei Objekten). Und Komposition bilde ich immer durch eine Member-Variable ab, die ja nicht null sein kann.

Michael E.

back to topic:

Effektiv C++ Programmieren Lektion 42 schrieb:

Benutzen Sie Layering [also die Klasse als Member einbinden], wann immer Sie können. Benutzen Sie private Vererbung, wann immer Sie müssen. Wann Sie müssen? Immer dann, wenn virtuelle Funktionen und/oder protected-Datenelemente [der Basisklasse] ins Spiel kommen [...].

Erklärung zu "protected-Datenelemente": Meyers bringt ein Beispiel, mit einer Basisklasse, von der kein Objekt erzeugt werden soll. Deshalb ist der Konstruktor protected. Beim Layering könnte man diese Klasse immer noch nicht instanziieren, während der Konstruktor bei privater Vererbung als private-Element der abgeleiteten Klasse zur Verfügung steht.