OOP ohne Vererbung?
-
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
-
Zeus schrieb:
Für Polymorphie brauch ich keine Interfaces
Und wie machst du das dann, wenn du keine Vererbung hast? Und statische Polymorphie ist hier nicht gefragt.
-
Bashar schrieb:
Das ist keine Eigenschaft der Vererbung.
Es ist aber eine Beziehung, die durch Vererbung in Sprachen wie Java oder C++ möglich wird. Wollen wir uns über terminologische Feinheiten unterhalten oder sagst du mir gleich, was du an meiner Aussage für falsch hältst?
naja schrieb:
Für Polymorphie kannst du auch Interfaces nehmen.
Nur sehr beschränkt. Ohne das Vorhandensein von Daten können viele hierarchische Strukturen nicht abgebildet werden. Ich erachte schon das Fehlen von Mehrfachvererbung in manchen Fällen als Einschränkung, Vererbung komplett wegzulassen scheint mir keine gangbare Alternative zu sein.
-
naja schrieb:
Zeus schrieb:
Für Polymorphie brauch ich keine Interfaces
Und wie machst du das dann, wenn du keine Vererbung hast? Und statische Polymorphie ist hier nicht gefragt.
In C und C++ wären zum Beispiel Funktionszeiger (oder eine Abstraktion davon) eine Möglichkeit. Aber auch diese haben ihre Einschränkungen.
-
Nexus schrieb:
naja schrieb:
Zeus schrieb:
Für Polymorphie brauch ich keine Interfaces
Und wie machst du das dann, wenn du keine Vererbung hast? Und statische Polymorphie ist hier nicht gefragt.
In C und C++ wären zum Beispiel Funktionszeiger (oder eine Abstraktion davon) eine Möglichkeit. Aber auch diese haben ihre Einschränkungen.
sag gleich, daß if ausreicht. stattdessen switch oder funktionszeigertabellen zu nehmen ist nur unbedeutende geschwindigkeitssteigerung.
-
Nexus schrieb:
naja schrieb:
Für Polymorphie kannst du auch Interfaces nehmen.
Nur sehr beschränkt. Ohne das Vorhandensein von Daten können viele hierarchische Strukturen nicht abgebildet werden. Ich erachte schon das Fehlen von Mehrfachvererbung in manchen Fällen als Einschränkung, Vererbung komplett wegzulassen scheint mir keine gangbare Alternative zu sein.
Man kann ja ein Interface implementieren und gleichzeitig eine has-a Beziehung zum Objekt, von dem du Daten brauchst, haben.
Übrigens habe ich nie gesagt, dass ich Vererbung ganz abschaffen würde, sondern nur die Alternativen aufgezählt. Ob man ganz ohne Vererbung auskommt (irgendwie sicher) und ob das dann besser oder schlechter ist, habe ich mir noch nie überlegt.
Nexus schrieb:
naja schrieb:
Zeus schrieb:
Für Polymorphie brauch ich keine Interfaces
Und wie machst du das dann, wenn du keine Vererbung hast? Und statische Polymorphie ist hier nicht gefragt.
In C und C++ wären zum Beispiel Funktionszeiger (oder eine Abstraktion davon) eine Möglichkeit. Aber auch diese haben ihre Einschränkungen.
Was von der Idee her auch ein einfaches Interface ist. Nur nicht das was ich dachte was du mit "Objekte als Basisobjekte behandeln" meinst. Ich dachte du beziehst dich da auf Polymorphie.
-
volkard schrieb:
sag gleich, daß if ausreicht. stattdessen switch oder funktionszeigertabellen zu nehmen ist nur unbedeutende geschwindigkeitssteigerung.
Kommt drauf an, was man unter Polymorphie versteht. Ich assoziiere damit unter anderem, dass der gleiche Anwendercode je nach Kontext etwas anderes tut, und dass die entsprechende Semantik bei der Verwendung implizit ausgewählt wird. Das ist bei If-Abfragen nicht direkt gegeben, schliesslich schreibt der Programmierer die Fallunterscheidung ausdrücklich hin.
