Das ist ja wohl nicht der eigentliche Sinn der Vererbung.

1. Was würdet ihr jetzt machen? Alles so sein lassen wie es ist, oder die Klassen auseinanderfrickeln?

2. Was habe ich da beim Design falsch gemacht? Die ursprüngliche Entscheidung, dass ein Pointercontainerwrapper auch ein Containerwrapper ist, kam mir damals eingentlich ganz logisch vor und so ganz sehe ich auch nicht ein, was daran falsch sein soll. Aber das Endergebnis spricht dafür, dass ich da falsch liege.

3. Das ist sowieso ein Problem, welches ich öfters habe, selbst bei einfachen Beispielen. Ich meine damit nicht den klassischen "Ein Auto ist ein Motor"-Fehlschluss. Aber auch wenn man beispielsweise ein Auto einer bestimmten Marke von einem generischen Auto ableiten würde, so würde man doch extrem viele Methoden überschreiben müssen, weil Autos verschiedener Hersteller sich in den Details der Bedienung doch öfters unterscheiden.

Gruß
Don06

Wieso musst du denn die Algorithmen anpassen?

Naja, schlecht gesagt. Eigentlich habe ich durch die Aktion die Algorithmen sogar zusammenfassen können. Ich hab's bloß ungeschickt gemacht, weil die Klasse halt langsam gewachsen ist. Ich hätte die Algorithmen gleich als freie Funktionen und nicht als Member implementieren sollen (das ist ein Fehler den ich ganz klar einsehe). Ich habe das jetzt so gelöst, dass die Containerwrapper die freie Funktion aufrufen, damit das Interface nicht gebrochen wird.

Don06 schrieb:

Also nach meinem Verständnis _benutzt_ du eine bestehende Container-Klasse um eine weitere (PointerContainer) zu implementieren. Es besteht also eine klare Has-a-Beziehung (wird implementiert durch). Eine Is-a-Beziehung sagt ja soviel wie, verhält sich (genauso) wie. Ein PointerContainer verhält sich nicht so wie ein Container (zumindest nach deiner Beschreibung). Vielleicht kannst du eine gemeinsame Basisklasse für (Value-)Container und PointerContainer finden, aber das hängt vom Kontext ab. Wie immer kann es dazu aber unterschiedliche Meinungen geben. Ach ja, ein oft genannter Tipp ist, nicht zu vererben um Code zu sparen, sondern nur, wenn es nötig ist (z.B. um virtuelle Funktionen der Basis zu überschreiben). Andernfalls immer Komposition vorziehen. Ausnahmen bestätigen natürlich die Regel.

Es sind Wrapper um einen bestehenden Container. Den bestehenden Container habe ich in der ersten Wrapperklasse per Komposition eingebunden. Und dann dachte ich mir, dass ich das Wrapperinterface noch anpassen könnte für den Fall, dass ein Pointercontainer gewrappt wird. Und daher habe ich den Pointercontainerwrapper vom Containerwrapper abgeleitet. Wobei wie gesagt die einzige Gemeinsamkeit am Ende war, dass sie beide den unterliegenden Container besitzen und dessen Größe einfach durchreichen.

3. Das ist sowieso ein Problem, welches ich öfters habe, selbst bei einfachen Beispielen. Ich meine damit nicht den klassischen "Ein Auto ist ein Motor"-Fehlschluss. Aber auch wenn man beispielsweise ein Auto einer bestimmten Marke von einem generischen Auto ableiten würde, so würde man doch extrem viele Methoden überschreiben müssen, weil Autos verschiedener Hersteller sich in den Details der Bedienung doch öfters unterscheiden.

Kannst du vielleicht noch ein anderes Beispiel bringen? Also irgendwas konkretes. Was du über deine PointerCollection schreibst verstehe ich nämlich nicht ganz. Bzw. wieso es da ein Problem geben sollte.

IMO ist ein PointerContainer<T> eben kein Container<T>, z.B. schonmal deswegen weil er ein anderes Interface hat. Daher sollte nix abgeleitet werden. Daher hätte ich es von Anfang an anders gemacht, daher verstehe ich das Problem nicht ganz

Den bestehenden Container habe ich in der ersten Wrapperklasse per Komposition eingebunden. Und dann dachte ich mir, dass ich das Wrapperinterface noch anpassen könnte für den Fall, dass ein Pointercontainer gewrappt wird. Und daher habe ich den Pointercontainerwrapper vom Containerwrapper abgeleitet. Wobei wie gesagt die einzige Gemeinsamkeit am Ende war, dass sie beide den unterliegenden Container besitzen und dessen Größe einfach durchreichen.

Jetzt versteh' ich gar nix mehr. Im ersten Beitrag schreibst du doch ausdrücklich "Eine neue Klasse PointerContainer von der Containerklasse abgeleitet"...

Den bestehenden Container habe ich in der ersten Wrapperklasse per Komposition eingebunden.

Das war schlau.

SeppJ schrieb:

Und dann dachte ich mir, dass ich das Wrapperinterface noch anpassen könnte für den Fall, dass ein Pointercontainer gewrappt wird. Und daher habe ich den Pointercontainerwrapper vom Containerwrapper abgeleitet.

Das kann ich nicht nachvollziehen.
Du mußt Dir die Frage stellen "Ist die Kuh wirklich ein Säugetier?" und nur wenn das stimmt, darfst Du erben.
Ist ein vector<int*> ein vector<int>? Nee. Das war's doch schon, oder? Weiterführende Literatur: Herr Bebel scnr

Eine neue Klasse PointerContainer von der Containerklasse abgeleitet (schließlich ist ein Pointercontainer auch ein Container)

Da steckt der Fehler. Der Pointercontainer ist auch eine Art Container, ja. Aber nicht so eine Art Container wie die, von der du abgeleitet hast.
Das ist so ein ähnliches Problem wie das "Quadrat ist ein Rechteck"-Problem: wenn ein Rechteck sich dadurch auszeichnet, dass es zwei unabhängige Kantenlängen hat, ist ein Quadrat kein Rechteck in diesem Sinne.

Das "Vererbung bedeutet ist-ein" ist keine vollständige Aussage. Es müsste heißen "Vererbung bedeutet ist-mit-der-kompletten-Semantik-ein". Womit Pointercontainer-Vererbung ausscheidet.