spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dr.hallo«

das ist was mir dazu einfällt, kann natürlich auch humbug sein.

Ist es. Das public vererben ist nichts anderes, als eine "ist ein"-Verknüpfung. Das heißt, dass wenn man einen Klasse CBird hat, dass man von dieser eine Klasse CEagle oder CRaven ableitet. Eine Wurst ist kein Supermarkt, wie du bereits sagtest, also stimmt die "ist ein"-Verknüpfung nicht mehr und somit ist public vererben hier absoluter Schwachsinn. Richtig wäre es, wenn man zum Beispiel von CWare CWurst und CBrot ableitet, aber auch von CLebensmittel. Diese Mehrfachvererbung würde Sinn ergeben. (Waren haben z.B. eine Anzahl, Lebensmittel einen Geschmack und Wurst und Brot beides).

Vererbung ist immer eine "Ist-Ein"-Bezeihung...

Ja. An dieser Stelle ging es eben AFAIK um public inheritance.

Das Schlimmste: in der zweiten Auflage wurden diese fatalen Fehler nicht behoben.

Zitat von »dr.hallo«

das wurstbrot besteht aus brot und wurst, also ist ein teil des wurstbrots sowhl wurst als auch brot.

Also sollte die Klasse Wurstbrot aus einem Objekt vom Typ Wurst und einem Objekt vom Typ Brot bestehen. Und nicht von Wurst und Brot ableiten, denn ein Wurstbrot ist eben nicht sowohl eine Wurst als auch ein Brot, sondern besteht aus Wurst und Brot.

Zitat von »dr.hallo«

das ist meiner meinung nach schon richtig, nur etwas gewöhnungsbedürftige mehrfachvererbung.

Nein, das ist völliger Schwachsinn.

Zitat

Richtig wäre es, wenn man zum Beispiel von CWare CWurst und CBrot ableitet, aber auch von CLebensmittel.

ja, das macht in der tat mehr sinn, schon kapiert! danke.

Private Vererbung heißt so viel wie "ist implementiert in Form von"...
Es wird nur die Implementierung geerbt und nicht die Schnittstelle. Das heißt im Grunde das selbe als würde man eine Instanz der Basisklasse als Member haben. Die Vorteile sind, dass man virtuelle Methoden überschreiben kann oder auf protected Member der Basisklasse zugreifen kann und sie sollte nur aus diesen Gründen angewandt werden.

(steht übrigens auch in Effective C++)

Imo modelliert Vererbung immer eine "ist ein" Beziehung, egal ob public, private oder protected. Der Unterschied ist nur, wer von dieser Beziehung weiß. Nach außen wirkt private Vererbung vielleicht wie eine "hat ein" Beziehung, aber von innen betrachtet, ist es immer noch eine "ist ein" Beziehung. Das kann man natürlich unter Umständen wie ein "ist implementiert in Form von" interpretieren. Aber egal, lassen wir das, ich glaub das verwirrt jetzt nur

..trotzdem finde ich den übergang hier fließend/verwirrend. in c++ spieleprogrammier erbt eine klasse CHybrid von CMinenleger und CJäger. ok, ein hybrid kann sowohl ein minenleger, als auch ein jäger sein, aber eben nicht ausschließlich eines der beiden. ist das denn hier nun auch so ein wurstbrotfrehler in abgeschwächter form?

Er ist ja auch nicht ausschließlich eins von beiden sondern gleichzeitg beides.
Egal wie du es wendest. Ein Wurstbrot ist niemals nie eine Wurst. Es ist eher ein Brot und hat Wurst.

Das Wurstbrotbeispiel ist sowieso sehr schlecht, weil man nicht viel mit einer Wurst und einem Brot anstellen kann.
Das Hybridbeispiel ist ebenfalls nicht so gut, weil man für das Verhalten, wie z.B. das legen von Minen, Module programmieren würde, die jedes Raumschiff enthalten kann. Das ist ein wesentlich besseres Design und so benötigt man keine extra Minenleger Klasse und, noch wichtiger, keine Mehrfachvererbung.

Diese beiden schlechten Beispiele zeigen auch, dass es nicht leicht ist ein gutes Beispiel für Mehrfachvererbung zu finden, das Anfänger auch noch verstehen können.
Für dich bedeutet das: Vergiss erstmal die Mehrfachvererbung und sammel Erfahrung in der OOP. Sobald du sie Sinnvoll einsetzen kannst wird es dir wieder einfallen.