Mehrfachvererbung

[Jester]

DEvent schrieb:

Java hat ja schon Interface, da wurde wohl gedacht wozu noch Mehrfachvererbung.

Insbesondere ergeben sich daraus viel weniger Probleme, als wenn mehrere Seiten eine Implementierung einer Funktion mitbringen. Bei der Benutzung von interfaces fallen viele Probleme der Mehrfachvererbung einfach weg.

Richtig eklig wird Mehrfachvererbung ja dann auch erst zusammen mit virtueller Vererbung. Dann bekommt man den gefürchteten Diamanten und den will man wirklich selten haben.

[Quodli Z.]

Dumme Sache das mit dem Moore'schen Gesetz - ausgerechnet jetzt, wo das Tempo durchschnittlicher PCs gerade erst anfing, Spaß zu machen.
Stimme aber vollkommen zu, Multicore,Multithreading und Multiprocessing wird eines
der Top-Themen in den nächsten 10 Jahren werden, hoffentlich mit geeigneter
Programmiersprachenunterstützung und nicht so künstlich "aufgepropft" wie manche OO-Modelle seinerzeit auf ehemals prozedurale Sprachen.

Obwohl ja meinem Eindruck nach bei der normalen täglichen Arbeit das Tempo der CPU heutzutage für die Mehrzahl der Anwender schnell genug ist;
was noch mehr stört, sind die zwei Bottlenecks CPU/RAM und RAM/Harddisk, vor
allem, wenn von einer speicheraufwendigen Anwendung zu einer anderen umgeschaltet
wird, sodaß alle Cachelines,Buffer und Speicherseiten neu gefüllt werden müssen.

[Gregor]

Quodli Z. schrieb:

was noch mehr stört, sind die zwei Bottlenecks CPU/RAM und RAM/Harddisk, vor
allem, wenn von einer speicheraufwendigen Anwendung zu einer anderen umgeschaltet
wird, sodaß alle Cachelines,Buffer und Speicherseiten neu gefüllt werden müssen.

Auch da wird es in Zukunft Lösungen geben, die dieses Problem mindern. Zum Beispiel "Die Stacking":

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2367&p=3

...und für Bereiche, in denen die Geschwindigkeit der Harddisk wichtiger als deren Kapazität ist, werden in Zukunft wohl "Solid State Disks" kommen. Samsung bereitet soetwas ja vor.

[Flow_cplus]

doofe Frage zwischenrein: Bezeichent man das schon als mehrfachableitung wenn man von mehreren interfaces erbt, oder erst wenn man "richtige" klassen hernimmt?

z.B .NET erlaubt nur eine basisklasse + mehrfache interfaces.In Java ja aehnlich.

Ich finde das oft nervig, da ich meist meine interfaces in nicht abstract classes packe sonder die interface class oft mit leeren funtionen fuelle um nicht immer alles ueberschreiben zu muessen und troztdem sichers stelle, alle funktionen sind implementiert.

Oft schwanke ich auch beim design hin und her zwischen feature in mutterklasse packen oder in ein eigenes object und mittels pointer auf interface verbinden.

Generell bin ich schon froh, dass es mehrfachvererbung gibt und aergere mich jedesmal wenn ich in ner umgebung arbeite wo das eingeschraenkt ist.

Habe aber auch schon informatiker getroffen die schwer dagegen gewettert haben und meinten ein gutes design habe nie mehrfachvererbeung ... .

Gruss
Flow

[info34]

[quote="Flow_cplus"
Habe aber auch schon informatiker getroffen die schwer dagegen gewettert haben und meinten ein gutes design habe nie mehrfachvererbeung ... .
[/quote]
Exakt.
Mehrfachvererbung ist ein antiquiertes Relikt, das zum Glück ausstirbt.

[Michael E.]

Flow_cplus schrieb:

Ich finde das oft nervig, da ich meist meine interfaces in nicht abstract classes packe sonder die interface class oft mit leeren funtionen fuelle um nicht immer alles ueberschreiben zu muessen und troztdem sichers stelle, alle funktionen sind implementiert.

Soll heißen?

[Gregor]

@Flow_cplus: Ich glaube, Du siehst die Interfaces aus einem etwas falschen Blickwinkel. Da wird nichts vererbt. Ein Interface ist die Definition einer Schnittstelle. Damit gibst Du nur an, dass eine Klasse eine bestimmte Schnittstelle zur Verfügung stellt. Sonst nichts.

Insofern würde ich das auch nicht als "Mehrfachableitung" oder so bezeichnen, sondern als Bereitstellung mehrerer Schnittstellen.

[M.Sc.]

Mehrfachvererbung kann einfach vom Design her nie richtig sein. Vererbung nennt sich auch Spezialisierung und man sollte immer "is a" oder zu deutsch "ist ein" sagen können. Programmierer die Mehrfachvererbung verwenden sollten besser auf das Delegation-Pattern zurück greifen.

BTW: Interfaces haben nichts mit Verbung zu tun, warum auch immer das manche behaupten!

[Artchi]

Die hier die Sprüche lassen, das Mehrfachvererbung falsches Design bedeutet, sollten auch mal ein paar Beispiele rüber wachsen lassen. Weil ihr nämlich so redet, als ob Bjarne Stroustrup und vorallem Andrei Alexandrescu mit ihrer Mehrfachvererbungs in ihren Büchern total falsch liegen. Vorallem letzterer hat mehrere Beispiele schon im ersten Kapitel. Oder was mache ich, wenn ich regen Gebrauch von Boost mache? Da komme ich hin und wieder garnicht drum herum Mehrfachvererbung einzusetzen. Aber hey, ich lasse mich gerne eines besseren belehren... aber dann bitte mit vernünftigen Beispielen. Danke!

[Flow_cplus]

Gregor schrieb:

@Flow_cplus: Ich glaube, Du siehst die Interfaces aus einem etwas falschen Blickwinkel. Da wird nichts vererbt. Ein Interface ist die Definition einer Schnittstelle. Damit gibst Du nur an, dass eine Klasse eine bestimmte Schnittstelle zur Verfügung stellt. Sonst nichts.

Insofern würde ich das auch nicht als "Mehrfachableitung" oder so bezeichnen, sondern als Bereitstellung mehrerer Schnittstellen.

Da stimm ich dir zwar zu, aber rein der technische vorgang unter c++ nennt sich nunmal vererbung ob das nun von abstracten basisklassen oder auch welchen voller funktionalitaet ist.

Rein prinzipiell wuerde ich das weniger unter vererben stellen.

[Quodli Z.]

Wenn ich Klassen für "Fortbewegungsmittel" definieren soll, und habe eine
Klasse für "Fahrzeuge" und eine für "Boote".
Ein Amphibienfahrzeug hätte dann Attribute von "Fahrzeug" und von "Boot",
und dann wäre es doch am nächstliegenden, wenn man aus "Fahrzeug" und "Boot"
jeweils das Passende and Attributen und Methoden nach "Amphibienfahrzeug" vererbt.
Ist das nun ein Design-Fehler ??

[M.Sc.]

Artchi schrieb:

Die hier die Sprüche lassen, das Mehrfachvererbung falsches Design bedeutet, sollten auch mal ein paar Beispiele rüber wachsen lassen.

Gegenfrage: Wann lässt sich Mehrfachvererbung nicht mit dem Delegation-Pattern umegehen? Das Satelliten Beispiel aus dem Buch erbt zum Beispiel von Task. Genau das ließe sich aber mit Hilfe einer Assosiation eleganter lösen. Denn ein Satellit hat eine/mehrere Aufgabe(n) und ist nicht eine Aufgabe.

Artchi schrieb:

Weil ihr nämlich so redet, als ob Bjarne Stroustrup und vorallem Andrei Alexandrescu mit ihrer Mehrfachvererbungs in ihren Büchern total falsch liegen. Vorallem letzterer hat mehrere Beispiele schon im ersten Kapitel. Oder was mache ich, wenn ich regen Gebrauch von Boost mache?

Nur weil die beiden es so machen ist es deswegen nicht gut. Warum haben die Entwickler bei Microsoft(C#) und Sun(Java) die Mehrfachvererbung weggelassen? Warum hat eine rein oo Sprache wie Smalltalk keine Mehrfachvererbung? Der Grund: Mehrfachvererbung widerspricht dem Vererbungsprinzip "ist ein"!

Artchi schrieb:

Da komme ich hin und wieder garnicht drum herum Mehrfachvererbung einzusetzen. Aber hey, ich lasse mich gerne eines besseren belehren... aber dann bitte mit vernünftigen Beispielen. Danke!

Wann kommt man nicht drumherum?

[Artchi]

Nur weil die beiden es so machen ist es deswegen nicht gut. Warum haben die Entwickler bei Microsoft(C#) und Sun(Java) die Mehrfachvererbung weggelassen? Warum hat eine rein oo Sprache wie Smalltalk keine Mehrfachvererbung?

Wie Marcus schon sagte: Mehrfachvererbung in eine Sprache zu implementieren ist mit viel Aufwand (auch Kosten in der Wirtschaft genannt) verbunden. Ein Feature als Bug zu bezeichnen, kann nur jemand sagen, der davon nicht profitieren kann.

Eine Gegenfrage: warum gibt es so nette Sprachen wie CaesarJ die genau dieses Defizit von Java kompensieren wollen? http://www.caesarj.org/ Komisch das es von der TU Darmstadt und den dort arbeitenden Profs entwickelt wird und auch noch von SIEMENS gesponsert wird, damit man endlich auf der Java-Platform unter anderem Mehrfachvererbung bekommt.

Der Grund: Mehrfachvererbung widerspricht dem Vererbungsprinzip "ist ein"!

Also wenn ich einen Dackel mit einem Terrier kreuze, dann ist der kleine Welpe der daraus kommt, kein Dackel-Terrier-Mischling? Was ist er dann? Nur ein Dackel? Oder nur ein Terrier? Das Beispiel mit dem "Amphibienfahrzeug" ist auch ein gutes Beispiel. Es ist ein Boot und ein Auto. Widerleg DAS mal!

[M.Sc.]

Ich habe es nicht als Bug bezeichnet sondern lediglich gesagt, dass es in der oo Welt auch Alternativen gibt! Die meisten Vorlesungen und Veröffentlichungen zu gutem und reinem oo Design bescheiben es so wie ich es tat. Man kann Probleme meistens auf verschiedene Weisen lösen und häufig ist keine der beiden Varianten unbedingt besser. Jedoch gibt es den Unterschied zwischen einem praktischen Design und einem gutem oo Design.

Artchi schrieb:

Der Grund: Mehrfachvererbung widerspricht dem Vererbungsprinzip "ist ein"!

Also wenn ich einen Dackel mit einem Terrier kreuze, dann ist der kleine Welpe der daraus kommt, kein Dackel-Terrier-Mischling? Was ist er dann? Nur ein Dackel? Oder nur ein Terrier?

Weiterhin ein Säugetier oder Hund, weil das andere nämlich Instanzen sind.

Artchi schrieb:

Das Beispiel mit dem "Amphibienfahrzeug" ist auch ein gutes Beispiel. Es ist ein Boot und ein Auto. Widerleg DAS mal!

Genau das ist ein Paradebeispiel für die Verwendung von Interfaces(nicht auf Java/C# bezogen). Wie wäre es mit AmphiFahrzeug erbt von Fahrzeug und implementiert das Interface Swimable?

[DEvent]

das Beispiel mit dem Amphibienfahrzeug kann man verschieden lösen.
Zum einen kann man eine neue Unterklasse Amphibienfahrzeuge definieren das von Fortbewegungsmittel erbt.
Zum zweiten kann man das State-Pattern machen (oder war das das Delegation-Pattern?). Ist das Fahrzeug auf Wasser werden die Methoden von Boote aufgerufen, auf Land die Methoden von Fahrzeuge.

Es gibt kein Beispiel das man nicht ohne Mehrfachvererbung lösen kann. Ob C++ oder Java beides ist Turing-Vollständig.

Mehrfachvererbung ist IMHO etwas für Leute die gerne das und dies hätten aber nicht darüber nachdenken wollen wie es machen.

Das Beispiel mit dem Dackel / Terrier ist nicht gültig. Du scheist Klassen und Attribute zu verwechseln. Beides sind Hunde. Ob es Dackel oder Terrier ist, entscheidet das Attribut Type. Oder willst du behaupten das ein Dackel etwas nicht kann was ein Terrier kann (oder umgekehrt) ?

[GPC]

DEvent schrieb:

Das Beispiel mit dem Dackel / Terrier ist nicht gültig. Du scheist Klassen und Attribute zu verwechseln. Beides sind Hunde. Ob es Dackel oder Terrier ist, entscheidet das Attribut Type. Oder willst du behaupten das ein Dackel etwas nicht kann was ein Terrier kann (oder umgekehrt) ?

Mein "Kleiner Münsterländer" ist ein Jagdhund, kann aber keine Schafe hüten. Oder willst du etwa behaupten, der einzige Unterschied von Hunden wäre ihr Aussehen?

[Artchi]

Pinguine sind auch Vögel, können die deswegen fliegen? Also, dann leite ich von Vogel ab, und implementiere die fliegen-Methode beim Pinguin leer. Also doch unterschiedliche Klassen. Ein Terrier grabt gerne Erde um (Terrier kommt von Tera), und ein Dackel jagt gerne, gräbt aber nicht gerade gerne Löscher in die Erde. Völlig zwei verschiede Verhaltensweisen. Wenn die jetzt nur unterschiedliche Fellfarbe usw. hätten, hätte ich das verstanden.

AmphibienFzg implements Swimable? Eh, und wo sind die Attribite für das Ruder und die Schrauben die das Fzg im Wasser vorantreiben? Schön und gut das meine Fzg ein Swimable-Methode hat. Aber von Ufer A nach Ufer B werde ich ohne Eigenschaften von einem Boot nicht weit kommen. Also brauche ich doch eine Klasse mit Eigenschaften und Methoden eines Bootes.

Umgekehrt genauso: Boot implements Driveable? Ohne vier Räder wirds auch schwierig damit zum Supermarkt zu fahren.

Leute, denkt doch mal nach... :p

[Artchi]

DEvent schrieb:

Das Beispiel mit dem Dackel / Terrier ist nicht gültig. Du scheist Klassen und Attribute zu verwechseln. Beides sind Hunde. Ob es Dackel oder Terrier ist, entscheidet das Attribut Type.

Also soll ich irgendwo eine switch-case-Anweisung haben um den Typ rauszufinden?

[M.Sc.]

Stimmt! Dieses problem lässt sich ohne Mehrfachvererbung nicht lösen.

Für mich ist hier EOD!

BTW: Hast Du Dir mal das oben von mir genannte Delegation-Pattern angeschaut?

[phlox81]

Artchi schrieb:

DEvent schrieb:

Das Beispiel mit dem Dackel / Terrier ist nicht gültig. Du scheist Klassen und Attribute zu verwechseln. Beides sind Hunde. Ob es Dackel oder Terrier ist, entscheidet das Attribut Type.

Also soll ich irgendwo eine switch-case-Anweisung haben um den Typ rauszufinden?

Nein, du hast einfach eine Stateklasse, die das dann über virtuelle Methoden
regelt, dann rufst du Hund::GetState auf, um den aktuellen Status zu bekommen.
Um zu wissen was für einen Hund du hast, musst du dann Hund::GetState()->toString()
aufrufen, alternativ kannst du auch Hund::GetCurrentStateType aufrufen, per RTTI
kannst du dann auf den zurückgegeben Typen abfragen.