Favour Composition over Inheritance - Aber Wann?

Firefighter

Klaro gerne:
http://www.harald-brandenburg.de/prog2/ueb/9/Aufgabe9.pdf

Das einzige was sich in meinen Augen unterscheidet ist die Sortierung die er am Ende will, ja und das hat ja nun recht wenig mit den Personen zu tuen, sondern das werd ich als Strategie anbieten.

Tachyon

Die "zusätzlich (mindestens)"-Formulierung ist ziemlich doof.
Einfach runtergelesen hätte der Student die Infos von Person, der Mitarbeiter die Infos von Student und der Prof die Infos von Mitarbeiter -> klingt wenig sinnvoll.
Ich denke mal eher, dass alle Personen sind, und der Prof außerdem einen Mitarbeiter darstellt.
Die Sortierungen wären dann einmal mit einem Personen-Sortierer machbar und einmal mit einem speziellen Studenten-Sortierer. Die Ausgabe sollte polymorph sein, da die Spezialisierungen zusätzliche Attribute haben, und Du dann wunderbar Personen-Objektreferenzen zur Ausgabe benutzen kannst.

Firefighter

Ok das waere dann eine Funktion die ich virtuell in der Person mache - die Funktion zur Ausgabe der jeweiligen Person.
Das wird der Brenner werden

volkard

Firefighter schrieb:

Ok das waere dann eine Funktion die ich virtuell in der Person mache - die Funktion zur Ausgabe der jeweiligen Person.
Das wird der Brenner werden

Das wird toll. Die void Professor::printAt(ostream&) ruft bevor Professor-Daten ausgegeben werden, die Mitarbeiter::printAt auf. Und diese wiederum ruft vor den eigenen Ausgaben die pur virtuelle aber trotzdem implementierte(!) Person::printAt auf.
Außerdem muß jeder sagen können, was er ist.

#####################################
# Professor
#####################################
Vorname: Hans
Nachname Meiser
...

Woher dem String "Professor" nehmen? Eine virtuelle char const* getClassName(), die in Person::printAt aufgerufen wird?

Firefighter

Ja ja das ist schon klar das ich das so machen muss.
Ich finds nur - naja. Aber werde es wohl so machen.

Michael E.

Tachyon schrieb:

Wenn die 3 spezialleren Typen nun aber Person aggregieren, dann würde das nicht mehr gehen.
Außerdem hat es rein vom Modell her einen schalen Beigeschmack, wenn ein Student eine Person hat, aber keine Person ist. Gespaltene Persönlichkeit?

Machs doch andersrum: Eine Person hat ein Attribut, das die zusätzlichen Informationen beinhaltet. Dieses Attribut kann sich selbst ausgeben. Dann brauchst du auch keine virtuellen Funktionen mehr.

Bei dieser Aufgabe kommt es vor allem auf die Gestaltung angemessen vieler, guter Klassen bzw. Klassenhierarchie(
n) an.

Damit ist wohl Vererbung "vorgegeben".

Shade Of Mine

http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives

Lustigerweise hat wikipedia sogar mal was passendes zu sagen

Firefighter

Shade Of Mine schrieb:

http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives

Lustigerweise hat wikipedia sogar mal was passendes zu sagen

Das ist Interessant. Aehnelt ja bissel dem Strategie-Muster.

Shade Of Mine schrieb:

http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Limitations_and_alternatives

Lustigerweise hat wikipedia sogar mal was passendes zu sagen

Hatte mir gerade auch sowas gedacht. Den Personen eine Rolle geben und Daten. Die Daten sind dann wieder eine extra Klasse, die man auch noch als Vererbungshierarchie aufbauen kann, damit sein Prof seine Vererbung bekommt. also class PersonenDaten, class StudentenDaten : public PersonenDaten.

pumuckl

TyRoXx schrieb:

Firefighter schrieb:

Ja das wird es wohl sein, das heisst wir koennen abschliessend sagen, das meine Frage im C++ Bereich nicht so einfach zu beantworten waere wie im Java/C# Bereich.

Damit ist auch alles geklaert fuer mich

So ein Unsinn, Objektorientiertung funktioniert in C++ genauso wie in C# oder Java.

Kommt drauf an, was du unter "Objektorientierung" verstehst. Falls du das "klassische" Polymorphie-Gedöns meinst, funktioniert es in C++ genauso, wenn man es "in reiner Form" betreibt. Durch die Dinge, die Java/C# nicht haben (vor allem Templates) ermöglicht C++ aber Techniken, die eine Klasse zu etwas anderem als einem klassich objektorientierten Element einer Vererbungshierarchie machen. Diese Abgrenzungen vom klassisch Objektorientierten sind aber nicht immer so leicht zu erkennen, so dass man geneigt ist, "best practices" aus Java/C# auf Fälle anzuwenden, auf die sie nicht angewendet werden sollten.