wieso ist mehrfachvererbung schlecht?
-
HumeSikkins schrieb:
Der Zusammenhang ist mir jetzt unklar. Was genau machst du denn in Java, wenn du von einer Klasse erbst und ein Interface implementierst und Basisklasse und Interface haben eine Methode mit gleichem Namen?
Gar nichts. Interface-Methoden sind immer abstract. Das ist übrigens das, was du mit "Protokollklassen" meinst. Diese enthalten nur abstrakte Methoden und keine Datenelemente. Das ist genau der Lösungsweg, den ich, genauso wie du, vorgeschlagen habe.
Denk doch nicht nur technisch, sondern auch mal logisch. Wenn ich zwei Basisklassenhabe, wenn ich also zwei Sachen bin und beide Basisklassen bieten ein Verhalten, dann ist es doch klar, dass ich entweder mein Verhalten anpassen muss (überschreiben) oder aber, dass ich mich für ein Verhalten entscheiden muss. Alles andere ist schizophren.
Da erscheint es mir aber eindeutig sinnvoller, ein Interface zu implementieren. Damit ist genauso sichergestellt, dass Derived sowohl vom Typ A als auch vom Typ B ist und trotzdem habe ich keine Mehrdeutigkeitskonflikte.
Mir fällt jetzt vor allem auch kein Beispiel ein, wo es sinnvoll wäre, dass ein Objekt sowohl ein A als auch ein B ist, aber trotzdem nur die Methode einer Basisklasse aufruft.
Und technisch hin oder her, das dynamische Binden ist im Eimer, was ich grundsätzlich schon mal nicht gut finde. Wohlgemerkt, dieses Problem hat man ja wirklich nur, wenn beide Basisklassen _konkrete_ Methoden definieren.Jetzt redest du wirr. Die bla-Methode in Derived überschreibt die bla-Methoden beider Basisklassen. Mal abgesehen davon, dass die Methoden alle private sind, würde der Aufruf von bla auf einem Derived-Objekt ganz korrekt Derived::bla aufrufen, egal ob über die Foo-, die Bar- oder die Derived-Schnittstelle.
Stimmt, da hab ich mich jetzt vertan. Btw, das mit dem private ist jetzt nicht der Punkt.
-
Optimizer schrieb:
Interface-Methoden sind immer abstract.
Ist mir bekannt.
Das ist übrigens das, was du mit "Protokollklassen" meinst.
Auch das ist mir bekannt.
Das ist genau der Lösungsweg, den ich, genauso wie du, vorgeschlagen habe.
C++-technisch sehe ich hier keinen Lösungsweg.
In Java kann eine Basisklassenmethode als Implementation einer durch ein Interface deklarierte Methode in einer abgeleiteten Klasse dienen.
Das ist in C++ aber nicht der Fall. Hier kann eine Basisklassenmethode niemals als "final overrider" einer rein virtuellen Methode einer anderen Basisklasse herhalten. Du musst die Methode also nach wie vor in der abgeleiteten Klasse überschreiben. Ansonsten bleibt die abgeleitete Klasse abstrakt.Da erscheint es mir aber eindeutig sinnvoller, ein Interface zu implementieren. Damit ist genauso sichergestellt, dass Derived sowohl vom Typ A als auch vom Typ B ist und trotzdem habe ich keine Mehrdeutigkeitskonflikte.
Hä? Die Mehrdeutigkeitskonflikte entstehen durch den Namen und sind unabhängig davon, ob deine Basisklasse nun eine Protokoll-Klasse ist oder nicht.
Und technisch hin oder her, das dynamische Binden ist im Eimer, was ich grundsätzlich schon mal nicht gut finde. Wohlgemerkt, dieses Problem hat man ja wirklich nur, wenn beide Basisklassen _konkrete_ Methoden definieren.
Nö. Das Problem ist unabhängig davon ob eine Methode eine Implementation hat oder nicht. Wenn zwei Basisklassen eine Methode mit selben Namen haben, dann muss die abgeleitete Klasse diese Methode überschreiben oder sie kann über die Schnittstelle der abgeleiteten Klasse nicht aufgerufen werden.
Tut mir leid. Ich kann dir wie so oft mal wieder nicht folgen.
-
C++-technisch sehe ich hier keinen Lösungsweg.
In Java kann eine Basisklassenmethode als Implementation einer durch ein Interface deklarierte Methode in einer abgeleiteten Klasse dienen.
Das ist in C++ aber nicht der Fall. Hier kann eine Basisklassenmethode niemals als "final overrider" einer rein virtuellen Methode einer anderen Basisklasse herhalten. Du musst die Methode also nach wie vor in der abgeleiteten Klasse überschreiben. Ansonsten bleibt die abgeleitete Klasse abstrakt.Stimmt, ich habe es eben ausprobiert. Ich war der festen Überzeugung, dass wenn nur eine ererbte Methode konkret ist, dass der Aufruf dann als eindeutig gilt.
Damit macht natürlich alles nachfolgende keinen Sinn mehr.
-
oh gott, fang niemals ne informatische diskussion an, wenn du nicht alle fachausdrücke auswendig kennst(und das in mehreren sprachen :D)
was bedeuted komposition in bezug auf klassen?
(und was sind interfaces)oh man, ich fühl mich so unwissend...
-
Komposition =
Bjarne Stroustrup schrieb:
Enthalten-Beziehung
(siehe TC++PL S.794)
interfaces = (in Bezug auf Klassen) Schnittstelle, (im Bezug auf Software) Benutzerschnittstelle, sprich visueller Kram ...mfg
Gladmring