Mehrfachvererbung und Interfaces
-
Hallo,
Ich habe schon ein bisschen in diesem (von mir leider viel zu selten besuchten Teil des Forums) herumgesucht und dazu nichts konkretes gefunden.
Das man Mehrfachvererbung von konkreten Klassen vermeiden sollte ist mir schon klar. ( Siehe Gründe in "Thinking in C++" )
Wie sieht das aber bei der verwendung von Interfaces aus? Oder giebt es einen generellen Grund auf Mehrfachvererbung zu verzichten? Ich impliziere Hier das meine Interface Klassen Root Klassen sind.
Mir schwebt da so etwas vor:
class IServer{.....}; class ICLient{.....}; class Router : public IServer, public ICLient{....};Vielen Dank
-
mal meine relativ unqualifizierte meinung dazu:
wenn du mehrfach von pure virtual klassen (das meinst du mit "interfaces", oder?) ableitest, dürfte das kein problem sein. es ist doch genau das erstebenswerte, mehrere komponenten zu einer zu verschweissen. oder hab ich die frage missverstanden?
-
Ich impliziere Hier das meine Interface Klassen Root Klassen sind.
Selbst, wenn Sie von weitere "Interfaces" (in C++ meißt Protokolle genannt) erben wäre das kein Problem.
Mehrfacherbung ist sowieso nicht prinzipell schlecht, schlimm oder böse. Viele verwenden Sie nur, obwohl Komposition oder ähnliches wesentlich besser geeignet wäre, nur weil man sich so manchmal nur weiterleitende Methoden sparen kann (aber zum Thema Forwarding gibt's ja schon 'nen netten Proposal für C++0x).
-
Gut,
Deshalb habe ich auch den Begriff "Interface" verwendet, weil er der eigentlichen Bedeutung näher kommt.
Leider kommt man, wenn man nur mal oberflächlich stöbert ganz schnell auf den Standpunkt das sie prinzipiell schlecht, schlimm oder böse ist.
@Korbinian:
Es geht mir weniger um das Verschweißen, sonder um das Rollenverhalten meiner Objekte in einem bestimmten Kontext und vor allem deren Anbindung an die GUI.z.B. kommt dann eben sowas raus
class CEndoViewDoc : public CDocument , public IZoomableObject
IZoomableObject ist ein Interface für einen Zoom Control - Client. Vorteil ist für mich, das ich diesses Control dann für beliebige Klassen frameworkunabhängig einsetzten kann.
Eine abstrakte Klasse muß doch aber nicht zwangsläufig eine Schnittstelle sein, oder? (Es geht mir dabei wirklich bloß um die Definition)
-
Eine abstrakte Klasse muß doch aber nicht zwangsläufig eine Schnittstelle sein, oder? (Es geht mir dabei wirklich bloß um die Definition)
Nein, eine Abstrakte Klasse kann trotzdem Methoden implementieren und Daten beinhalten, was bei Schnittstellen nicht der Fall ist.
-
Wer nutzt denn in C++ die Bezeichnung "Protokoll"? Das hab ich bisher nur bei ObjC und CLOS gehört.
-
Vielleicht habe ich auch nur einen falschen Eindruck bekommen. In letzter Zeit habe ich mit meheren Leuten gesprochen, die es Protokolle nannten und nie Schnittstelle.
-
Leider kommt man, wenn man nur mal oberflächlich stöbert ganz schnell auf den Standpunkt das sie prinzipiell schlecht, schlimm oder böse ist.
Was waere die Welt ohne Vorurteile
richtiger waere:
Mehrfachvererbung foerdert Probleme bei schlechten Design viel eher ans tageslicht als eben ohne.
Wenn du Dir die Standpunkte und die zugrunde liegenden Dokus richtig zu gemuete fuehrst, lernst recht schnell was bei mwehfachvererbung zu beachten hasst, und wie vorrausschauend und sauber man seine Schnittstellen zu definieren hat.und ebenfalls wichtig:
Mehrfachvererbung kann ungemein helfen, generische Biblithoken schlank zu halten, Anstatt die anzahl der Klassen einer bibo im verhealtniss zum kreuzprodukt aller Anforderungerung anwachsen zu lassen Siehe ATL/WTL <-> MFC ....Ciao ...
-
Helium schrieb:
Eine abstrakte Klasse muß doch aber nicht zwangsläufig eine Schnittstelle sein, oder? (Es geht mir dabei wirklich bloß um die Definition)
Nein, eine Abstrakte Klasse kann trotzdem Methoden implementieren und Daten beinhalten, was bei Schnittstellen nicht der Fall ist.
Schnittstelle kann auch reine virtuelle Methode implemetieren.
-
wenn du mehrfach von pure virtual klassen (das meinst du mit "interfaces", oder?) ableitest
Es gibt keine "pure virtual Klassen".
Wer nutzt denn in C++ die Bezeichnung "Protokoll"?
Scotter Meyers, Herb Sutter, John Lakos um nur einige zu nennen.
-
Ich denke, das was du meinst ist "ist implementiert mit"? Also analog zum Java-Interface?
Weil dafür gibts dann in C++ die private "Vererbung" (hab ich extra in Anführungsstrichen!).
class Hund : public Tier : private XYInterface {}In dem Fall ist Hund von Tier abgeleitet (Hund ist ein Tier) und hat die Implementierung XYInterface. Wobei das hier KEINE Mehrfachvererbung ist. Das klommt allerdings denke ich deinem gewünschten Interface nahe.
-
Artchi schrieb:
Ich denke, das was du meinst ist "ist implementiert mit"? Also analog zum Java-Interface?
Weil dafür gibts dann in C++ die private "Vererbung" (hab ich extra in Anführungsstrichen!).
Java-Interfaces haben weder mit "ist implementiert mit" noch mit privater Vererbung auch nur das geringste zu tun.
class Hund : public Tier : private XYInterface {}In dem Fall ist Hund von Tier abgeleitet (Hund ist ein Tier) und hat die Implementierung XYInterface. Wobei das hier KEINE Mehrfachvererbung ist. Das klommt allerdings denke ich deinem gewünschten Interface nahe.
Das ist ein Syntaxfehler. Solltest du class Hund: public Tier**,** private XYInterface gemeint haben: Natürlich ist das Mehrfachvererbung.
-
@Artchi
Interface + private Vererbung ist ein widerspruch in sich. Ich glaube du sitzt hier einer furchtbaren Verwechslung auf.
-
Eher entschpricht "implements Interface" in Java der "public" Vererbung als der "private" Vererbung in C++.
-
implements in Java entspricht IMO der public Vererbung in C++ mit pure virtual Klassen.
Ich benutze sowas, um bestimmte Eigenschaften sicherzustellen, in der Java-API kann man das ganz gut sehen. Da gibt es Interfaces wie Cloneable, Compareable, etc.
-
Optimizer schrieb:
implements in Java entspricht IMO der public Vererbung in C++ mit pure virtual Klassen.
Ich benutze sowas, um bestimmte Eigenschaften sicherzustellen, in der Java-API kann man das ganz gut sehen. Da gibt es Interfaces wie Cloneable, Compareable, etc.Stimmt. Nur ist Clonable eine der schlecht entworfenen Schnittstellen.
-
Optimizer schrieb:
implements in Java entspricht IMO der public Vererbung in C++ mit pure virtual Klassen.
Ich benutze sowas, um bestimmte Eigenschaften sicherzustellen, in der Java-API kann man das ganz gut sehen. Da gibt es Interfaces wie Cloneable, Compareable, etc.HumeSikkins schrieb:
Es gibt keine "pure virtual Klassen".
Da hab ich fast lust den Spruch "Wer lesen kann ist klar im Vorteil" zu bringen.
-
Da hab ich fast Lust, den Spruch "wer denken kann, wird es schon verstehen" zu bringen.
-
HumeSikkins schrieb:
Es gibt keine "pure virtual Klassen".
hm, dann hab ich wohl was verwechelt. was ist dann eine klasse, die etwa so aufgebaut ist:
class MyClass { virtual void myFunc() = 0; }war es nicht so, dass man von diesen klassen keine instanz bilden kann, und sie deshalb irgendwie speziell heissen?
*amschlauchsteh*
-
«abstrakt»