OOP ohne Vererbung?
-
Bashar schrieb:
Zur Klarstellung: Bei solchen Forderungen ist mit Vererbung in der Regel die Klassenvererbung gemeint. Mit Interface-Vererbung hat eigentlich niemand ein Problem. Richtig?
äähm nein ich schon
-
OK, das hat natürlich keiner von den Herren gesagt. Also mal wieder viel Tamm Tamm um nichts.
-
Wenn man komplett plem ist kann man Interfaces auch noch abschaffen, und wie in Python alles über Duck-Typing machen *würg*
-
Oder strukturell Typesystem wie Scala, Rust, M,...
-
Googles Go hat IIRC so ein Konzept.
Ja, geklaut von Haskell (und davor hats auch schon bestimmt jemand verwendet).
Ich frage mich jetzt, ob das wirklich praktikabel wäre?
Ja, gibt auch einen Artikel warum erben von Implementation in Java schlecht ist. Wurde in einem Thread hier mal verlinkt, finde ich aber nicht mehr.
Würde man da nicht wieder bei der proceduralen Technik landen, nur halt mit privaten Variablen?
Im Falle von Haskell sicher nicht. Und ja, es ist OOP.
Wie könnte man z.B. Vererbung in den heutigen OO-Sprachen eliminieren?
Indem man das Schluesselwort extends aus Java streicht oder in C++ nur von Klassen mit pure virtual functions erben darf.
Aber warum sind alle gleich immer fuer verbieten? In Sprachen wie Haskell passt es zum Gesamtkonzept, aber in Java und C++ eben nicht. Hier hat aber der Programmierer selbst die Moeglichkeit, durch Disziplin auf extends und aehnliches zu verzichten.
-
hustbaer schrieb:
Wenn man komplett plem ist kann man Interfaces auch noch abschaffen, und wie in Python alles über Duck-Typing machen *würg*
Ist das Thema jetzt durch und der Thread zum Abschuss freigegeben?
-
Was genau ist denn die Ersatzlösung für Vererbung? Bspw. GUIWidget -> Button -> ClickButton / SwitchButton, etc. ist jetzt nur ein Beispiel. Wie sieht das denn dann aus (OOP ohne Vererbung)?
MfG SideWinder
-
Vererbung bläht doch nur den Code auf obwohl es dazu gedacht war das Gegenteil zu bewirken. Ja kann man vergessen.
-
SideWinder schrieb:
Was genau ist denn die Ersatzlösung für Vererbung?
Keine. hihi.
Bei mir sind im Anwendungscode 95% der Klassen solo und nur 5% möchten sich in eine Vererbungshierarchie einreihen.
Bibliotheken, die ich baue, erben etwas mehr rum. Und grafische Bibliotheken, die ich nicht baue, würdem noch viel mehr rumerben. Wenn ich wie in manchen Sprachen Bibliotheken als gottgegeben hinnehmen würde, könnte ich ohne großen Schaden von Vererbung nichts wissen und die Welt wäre gut.
Ich experimentiere gerade ein wenig mit C++0x und dem bewüßten Verzicht auf nur technisch bedingte Vererbung wie er zum Beispiel in der std::streamlib geschah. Ich kann leider noch nichts darüber sagen. Vermutlich geht es wie sonst bei meinen Verzichtsexperimenten aus, daß ich feststelle, daß man doch hin und wieder aber selten Vererbung benutzen sollte, obwohl das Modell gar keine Vererbung braucht, und zwar nicht aus Mikrooptimierungsgründen, sondern weil die technich unnütze Vererbung dann doch mal das Denken vereinfacht, und in irgendeinem Grenzfall sogar so massiv, daß ich sie allgemein nicht missen möchte.
Das zur unnützen Vererbung.
Wenn das Modell Vererbung vorsieht, wie "Die Kuh ist ein Säugetier" geht eh kein Weg daran vorbei, das zu implementieren.
-
Bashar schrieb:
hustbaer schrieb:
Wenn man komplett plem ist kann man Interfaces auch noch abschaffen, und wie in Python alles über Duck-Typing machen *würg*
Ist das Thema jetzt durch und der Thread zum Abschuss freigegeben?
Weiss nicht.
Ist aber meine ehrliche Meinung.
OOP ohne Interfaces und ohne Vererbung = Typsicherheit ade = Katastrophe für grössere Projekte.
-
OOP ohne Vererbung wäre sicher kein Problem und meistens sogar besser. OOP ohne Interfaces wäre nicht so toll. Interfaces und Vererbung sind ja auch was komplett unterschiedliches. Ohne Interfaces, könnte man Objekte haben, die Funktionen mit bestimmten Signaturen implementieren und dann so eine Funktion z.B. als clickCallback registrieren. Typsicherheit ist also trotzdem möglich.
-
Artchi schrieb:
Egal, jedenfalls gibt es da so ein paar Gestalten, die davon schwärmen, die Vererbung abschaffen zu würden, weil sie in OOP nur die Kapselung für ausreichend halten.
Das sind garantiert Anhänger von OO-Sprachen mit dynamischen Dispatching, die Duck Typing ganz toll finden und meinen mit Unit Testing könne man alle Probleme lösen. Oder irre ich mich da?
Fakt ist. Es gibt im Grunde bei den Entwickler zwei Grundströmungen: Die einen favorisieren strenge Typisierung und die anderen sind für schwach oder gar ungetypte Systeme. Die Diskussion ist schon alt und es ist nichts zu erwarten, daß dieser Streit jemals zu Ende geht. Auch wenn ich mich da an einen Artikel erinnere der vollmundig verspricht "the language wars are over".
-
~john schrieb:
Das sind garantiert Anhänger von OO-Sprachen mit dynamischen Dispatching, die Duck Typing ganz toll finden und meinen mit Unit Testing könne man alle Probleme lösen. Oder irre ich mich da?
Vermutlich irrst du dich. Eigentlich hatte ich Artchi mit meiner ersten Antwort fragen wollen, dass er das mal klarstellt, aber ich hab mich wohl falsch ausgedrückt, so dass er das nicht als Frage aufgefasst hat
Jedenfalls hat das, wenn es das ist, was ich meine, nichts mit statisch vs. dynamischer Typprüfung zu tun. Es gibt weiterhin statische Typen. Es gibt lediglich keine Vererbung von Implementierungen mehr. Also Subtyping vs. Subclassing.
Um statische vs. dynamische Typprüfung kann es eigentlich nicht gehen, zumindest haben die mir bekannten dynamischen OOP-Sprachen alle Vererbung (Smalltalk, Python, CLOS).
-
Was hat Vererbung auch mit statisch vs. dynamischer Typprüfung zu tun?
-
Bashar schrieb:
Vermutlich irrst du dich. Eigentlich hatte ich Artchi mit meiner ersten Antwort fragen wollen, dass er das mal klarstellt, aber ich hab mich wohl falsch ausgedrückt, so dass er das nicht als Frage aufgefasst hat
Habe es als Erklärung verstanden. In den bisher von mir gelesenen Interviews wird nur von Vererbung gesprochen. Es wird nicht klar gesagt, ob Klassen und/oder Interfaces.
Leider geben die Gegner auch keine konkreten Alternativen an. Sondern sie finden es einfach nur doof.
-
Artchi schrieb:
Leider geben die Gegner auch keine konkreten Alternativen an. Sondern sie finden es einfach nur doof.
Die sind ja auch bekannt. Aggregation, has-a, Composition, Delegation...
-
naja schrieb:
Aggregation, has-a, Composition, Delegation...
Damit kann man aber zentrale Eigenschaften der Vererbung nicht ausdrücken. Zum Beispiel abgeleitete Objekte als Basisobjekte behandeln.
-
Nexus schrieb:
Damit kann man aber zentrale Eigenschaften der Vererbung nicht ausdrücken. Zum Beispiel abgeleitete Objekte als Basisobjekte behandeln.
Das ist keine Eigenschaft der Vererbung.
-
Nexus schrieb:
naja schrieb:
Aggregation, has-a, Composition, Delegation...
Damit kann man aber zentrale Eigenschaften der Vererbung nicht ausdrücken. Zum Beispiel abgeleitete Objekte als Basisobjekte behandeln.
Für Polymorphie kannst du auch Interfaces nehmen.
-
Für Polymorphie brauch ich keine Interfaces
