Mehrfachvererbung
-
Hallo:
Ist jemand von Euch mal auf ein Programm-Problem gestoßen, das
unabdingbar multiple inheritance (mi.) voraussetzte und bei Verzicht
auf mi. gar nicht oder nur mit großem Zusatzaufwand zu lösen war ??Oder - allgemeiner formuliert (hinsichtlich Leistungsfähigkeit von C++,Java,C#,
Python,Ruby & Co.):
Hat es tatsächlich in der Praxis spürbare Konsequenzen für den Programmierer, ob eine Progr.Sprache mi. unterstützt oder ist das mehr eine Stilfrage ??
-
schau dir mal den thread "Getreide und das observepattern" oder so im C++-Forum an
ich würde mal sagen,. da gehts nich anders
-
Mithilfe der mehrfachvererbung lassen sich viele dinge einfach eleganter lösen.
Man kann natürlich hergehen und jede klasse neu schreiben, jedoch wäre ein soclher code nurnoch schwer wartbar (Dank der Vererbung muss man oft nur die basisklasse einaml anpassen)Größenteils ist es also eine Stilfrage und die Frage wieviel arbeit man sich machen will, schreibe ich 10 mal den selben code oder nur einmal und vererbe ihn.
-
Es gibt selbst bei der Nasa Programme die Mehrfachvererbung einsetzen. Bjarne Stroustrup hatte mal so ein Beispiel mit einem Satteliten in sseinem Buch beschrieben, wo real Mehrfachvererbung zum Einsatz kam, wei es ganz einfach nötig war.
Natürlich könnte man es auch ohne Mehrfachvererbung lösen, jedoch mit einem Mehraufwand. Denn "geht nicht, gibts nicht". Aber darum geht es ja nicht. In C++ hab ich halt die _Möglichkeit_, es ist kein Zwang. Die Mehrfachvererbung wird gerne von den Leuten verteufelt, die in ihrer Lieblingssprache keine Möglichkeit dazu haben.
Ich selbst habe aber bisher seeehr selten davon Gebrauch gemacht.
-
Artchi schrieb:
[..] Denn "geht nicht, gibts nicht".[..]
In Java schon.
-
dragon90# schrieb:
Artchi schrieb:
[..] Denn "geht nicht, gibts nicht".[..]
In Java schon.
Artchi wollte damit wohl auf folgendes hinaus:
-
Kann man denn in Sprachen, die *keine* Mehrfachvererbung kennen,
Large-Scale-Projekte (mit, sagen wir, 1+ mio Programmzeilen) mit vernünftiger Erfolgsaussicht realisieren ?Ohne OOP geht so etwas ja wahrscheinlich nicht /* es sei denn, man macht öfter
Refactoring als make
*/, aber geht's auch ohne
Mehrfachvererbung nicht ??
-
Natürlich gehn auch große Projekte ohne Mehrfachvererbung.
Das erste was mir da einfällt ist der linux-kernel.Aber es gibt noch viele projekte die in reinem C geschrieben sind.
-
Mehrfachvererbung ist oft der geradlinigere Weg. Man denkt sich was aus und stößt dann irgendwann auf einen Punkt wo man denkt "hier wär jetzt Mehrfachvererbung geil".
Der Witz an der Sache ist, dass man damit zu 80% falsch liegt und man schon auf dem Weg hierhin Design-Fehler eingebaut hat. Für mich ist die wichtigste Feststellung immer nur, dass man Mehrfachverbung seltener wirklich "braucht", als viele Leute denken. Die einfache Rechnung "ein Eisbär IST ein Landtier (statt Vogel, Fisch) und IST ein Polartier (statt Tropentier, gemäßigte-Klimazone-Tier)" geht nicht auf, weil man das so modelliert in einer realen Anwendung nicht braucht. Es geht nicht darum, die Umwelt nachzubilden, sondern das abzubilden, worauf es im Programm dann ankommt und das ist dann fast immer nur eines davon.
Bei 10% wäre es nicht verkehrt, aber wenn man größere Teile anders macht (nicht schlechter) kommt man gut darum herum. Mehrfachvererbung nicht zu brauchen, ist jedenfalls mal kein Nachteil. Bei 10% dann kann man mit Mehrfachvererbung eine elegantere Lösung finden und ärgert sich, dass man sie nicht hat.
Und hier scheiden sich jetzt die Geister: Soll man für diese seltenen Fälle Mehrfachvererbung anbieten? Oder soll man zu Gunsten eines einfacheren und performanteren Modells und eines übersichtlicheren Vererbungsgraphen (ohne mögliche Zyklen) Mehrfachvererbung generell vermeiden? Tja, da gibt's wohl keine einheitliche Meinung von.
-
Optimizer: Sehr aufschlußreich, Danke.
Mich wundert ein bisschen, daß in einigen Sprachen, die neuer als C++ sind,
die Mehrfachvererbung wieder fallen gelassen wird (Java, Ruby), weil es doch
ungewöhnlich ist, daß Sprach-Features, die sich einmal als nützlich erweisen, in
der "Programmiersprachen-Evolution" *nicht* weitergegeben werden. Das meiste
andere, was zur Beherrschung immer komplizierterer Programmprojekte vorteilhaft
war (Hochsprachen, Datenstrukturen, Strukturierte Programmierung, OO, ...) wird doch von Sprache zu Sprache weitergegeben und nicht irgendwann wieder
fallengelassen, bevor ein noch besserer Ersatz zur Verfügung steht (was könnte
aber im Augenblick ein besserer Ersatz für OOP+Mehrfachvererbung sein ??).Na, wie dem auch sei... muß man aus dem oben Erwähnten schließen, daß die
Vorteile der Mehrfachvererbung nicht so groß sind, um sie in der zukünftigen
Sprachevolution "mitzuschleppen", oder sind Java und Ruby nur Ausnahmen von der
Regel ?Und noch eine Frage, falls sich jemand außer mir noch für sowas interessiert:
Was kommt denn als nächstes *nach* der OOP?
Schaut man sich die "Break-throughs" mal zeitlich an:
ca. 1950 - Hochsprache, FP
ca. 1970 - Strukturierte Progr.
ca. 1990 - OOP
ca. 2010 - ??
dann wäre 2010 der Durchbruch für das *nächste* Konzept fällig.
Nur: Welches ? Vielleicht die Kombination von FP und OO, wie man sie in
C#, Ruby und Python findet? Oder gibt es in den Forschungslabors schon
was ganz Neues an Prog.Sprachenkonzepten, das nur noch nicht im Licht
der Öffentlichkeit steht?
-
Die Mehrfachvererbung ist der Prüfstein für die Sprachdefinition und die Compilerbauer - das ist wahrscheinlich daher eines der Features, die ein Kostenrechner am ehesten streicht, da der Aufwand der Definition/Implementation sehr hoch ist.
-
Quodli Z. schrieb:
Und noch eine Frage, falls sich jemand außer mir noch für sowas interessiert:
Was kommt denn als nächstes *nach* der OOP?
Schaut man sich die "Break-throughs" mal zeitlich an:
ca. 1950 - Hochsprache, FP
ca. 1970 - Strukturierte Progr.
ca. 1990 - OOP
ca. 2010 - ??
dann wäre 2010 der Durchbruch für das *nächste* Konzept fällig.
Nur: Welches ? Vielleicht die Kombination von FP und OO, wie man sie in
C#, Ruby und Python findet? Oder gibt es in den Forschungslabors schon
was ganz Neues an Prog.Sprachenkonzepten, das nur noch nicht im Licht
der Öffentlichkeit steht?Forschung gibt es zuhauf. Als nächstes steht wohl die große Parallelisierungswelle an. Nachdem die Prozessoren nicht mehr schneller werden können, müssen sie jetzt bald 128 Kerne haben und die wollen ausgenutzt werden. Heutige Verfahren skalieren sehr schlecht mit der zunehmenden Anzahl von Hardware-Threads, da müssen andere Denkweisen her.
Ich denke, dass sich OOP noch länger hält und zunehmend mit anderen Stilmitteln kombiniert wird. Im Moment ist OOP häufig mit imperativem Programmierstil kombiniert, vielleicht wird dieser dann zunehmend funktionaler. Attribute haben auch Einzug in Mainstream-Sprachen erhalten, an der Weiterentwicklung von C# und Java kann man das IMHO auch ein bisschen sehen.
-
Java hat ja schon Interface, da wurde wohl gedacht wozu noch Mehrfachvererbung.
-
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.
-
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.
-
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.
-
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
-
[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.
-
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?
-
@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.