NULL
-
Shade Of Mine schrieb:
sag niemals nie.
aber klar MI mit klassen die verhalten definieren ist nicht oft notwendig. meistens vererbt man in c++ deshalb ja auch nicht.
und genau das ist eben meine kritik an java interfaces - dort vererbt man dauernd. und klassen die 10 interfaces implementieren sieht man recht häufig.
Hm, hast du Beispiele? Ich hab das z.B. noch nie gesehen.
-
Shade Of Mine schrieb:
Du definierst Interfaces über implements.
Aua!
Ich definiere Konzepte.
Irgendwann verstehst du das auch, keine Angst.Ich glaube nicht, dass ich dein wirres Gerede verstehen möchte. Dazu verdrehst du zusehr das was ich geschrieben habe.
Wusstest du dass in Sprachen mit einem interface schlüsselwort deutlich tiefere und häßlichere hierachien existieren als in sprachen ohne?
Ist das jetzt ein Postulat von dir oder kannst du das irgendwie beweisen?
Schau dir beliebigen Code an. Allein zB die Java Library und die STL.
"Beliebigen Code"? LOL. Beliebig schlechten?
Es ist also nur ein Shade-of-mine Postulat und nicht viel dahinter.TAble ist das Interface dass von T implementiert wird damit sich T wie ein T verhalten kann. Ist eine furchtbare Erfindung sowas. Weil du nämlich enorm unflexibel bist.
Wieder nur eine leere Behauptung. Hast du es je ausprobiert, oder gründet sich diese Expertise nur auf deinem breit gefächerten Schatz an angelesenem Halbwissen?
Ich mach das jeden Tag, meine Kollegen machen das jeden Tag. Wir lösen alle Probleme schnell, sicher und flexibel.Das meine ich mit Interfaces implementieren aber keine Schnittstellen. In Sprachen mit Ducktyping hast du plötzlich überhaupt keine Interfaces mehr. Wie kannst du also allen ernstes Behaupten Interfaces sind ein wichtiges Konzept dass über vererbung nicht realisiert werden kann? Oder redest du dich gerade nur heraus weil du blödsinn geschrieben hast?
Den Blödsinn schreibst du, weil du mir Sachen in den Mund legst, die ich so nicht gesagt habe.
Zu UnsupportedOperationException: Ja, die ist scheiße. Aber wer redet von Java? Wer sagt, dass die Standard-API von Java ein gutes Beispiel für Objektorientierung ist? Ganz im Gegenteil. In einem guten Design kommt man gut ohne UnsupportedOperationException aus.
Sowas ist ein Standardproblem wenn du dauernd Interfaces hast
Nein ist es nicht. Nur wenn man zu blöd ist, sie richtig einzusetzen.
Denn es macht aus stark typisierten sprachen schwach typisierte.
Du dir einen Gefallen und erweitere dein Halbwissen, in dem du nachschlägst was "schwache" und "starke" Typisierung bedeutet. Dann finde heraus was "dynamische" und "statische" Typsierung ist (nur davon schrieb ich). Dann wirst du hoffentlich sehen, dass es hier einen gewaltigen Unterschied gibt.
Wenn nicht, frag nach. Aber was red ich. LSP hast du ja auch nicht ergooglet...Aber bitte wenn du Java und C++ nicht hernehmen willst für Beispiele (Ruby und Python und die meisten anderen Sprachen wirst du ja auch nicht wollen denn dort definieren sich Interfaces ja idR über schnittstellen - nur sehr wenige Sprachen haben dieses Interface Konzept (und die hauptsächlich wegen den bereits von mir genannten technischen limitierungen)) dann sag doch welche Sprache du als Beispiel verwenden willst.
Sehr wenige Sprachen? Von den bekannten, modernen (statisch getypen) OO-Sprachen haben die meisten Interfaces (z.B. Java, C#, Delphi, D). C++ hat keine, aber C++ ist auch nicht modern.
Komisch, dass die Designer dieser neuen Sprachen dieses enorm unflexible , bescheuerte Interface-Konzept verfolgen. Wahrscheinlich sind die alle so blöd wie ich...
-
Shade Of Mine schrieb:
Ein Interface ist aber wirklich so ziemlich nichts. Es ist nur noetig bei stark typesierten Sprachen, es sagt nur das eine Klasse das Interface anbietet, aber das Interface selbst kann nichts machen. Z.B. kann ich zwar das List-Interface implementieren, aber die Methoden des Interface leer lassen.
Nein, das hat nichts mit stark typisierten sprachen zu tun. man kann interfaces in schwach typisieren sprachen haben und man kann stark typisierte sprachen ohne interfaces haben.
Interessant, wie geht den das ohne Interfaces in einer stark typ. Sprache? Templates ist der Versuch in C++ das Konzept einer schwach typ. Sprache einzufuehren.
Shade Of Mine schrieb:
aber die frage ist: meinst du mit Interface das Konzept eines Interfaces (also ==ABC) oder java interfaces?
Wieso reitet ihr eigentlich auf der UnsupportedOperationException rum, obwohl in einer schwach typ. Sprache das genauso gehandhabt wird? (dort gibt es eine Laufzeit-fehler wenn du einen Typ verwendest, der das Interface gar nicht anbietet, z.B. in JavaScript oder PHP).
PS: Was ist ein Closable Interface?
-
tfa schrieb:
[...]C++ hat keine, aber C++ ist auch nicht modern[...]
Hat es nicht? Komisch. Irgendwie benutze ich in C++ ständig Interfaces. Zur Kompilierzeit über Templates, zur Laufzeit über rein abstrakte Basisklassen zur Laufzeit und über Funktionszeiger. Je nach wunsch muss ich dafür auch nicht irgendwas vererben.
Ich verstehe nicht, was an der verkorksten Weise wie in Java (C#, Delphi...) Schnittstellen bereit gestellt werden müssen so toll sein soll.
-
OK, dann macht ihr euer Ding, ich mach meins, wir hören auf zu streiten und alle sind zufrieden. Amen.
-
tfa schrieb:
Sehr wenige Sprachen? Von den bekannten, modernen (statisch getypen) OO-Sprachen haben die meisten Interfaces (z.B. Java, C#, Delphi, D). C++ hat keine, aber C++ ist auch nicht modern.
Komisch, dass die Designer dieser neuen Sprachen dieses enorm unflexible , bescheuerte Interface-Konzept verfolgen. Wahrscheinlich sind die alle so blöd wie ich...Das Konzept der Interfaces ist aber auch sehr alt. C++ hat nur keine weil die Designer von C++ es wieder mal besser machen wollten. Wieso Interface wenn man doch gleich die sehr viel maechtigere MI anbieten kann. In der Theorie hoert sich das doch so gut an :p
-
In der Theorie hoert sich das doch so gut an
Nicht nur in der Theorie.
-
tfa schrieb:
OK, dann macht ihr euer Ding, ich mach meins, wir hören auf zu streiten und alle sind zufrieden. Amen.
...und alles nur, weil ich JustAnotherNoob's pointer-hack komisch fand.
-
...und alles nur, weil ich JustAnotherNoob's pointer-hack komisch fand.
Es sollte austauschbar mit Pointern und Smartpointern sein(sowohl manuell als auch in Templates) => gleiche Syntax
das ist alles was ich damit sagen wollte und es hat sich bewährt, ich habs schon mehrmals nachträglich eingebaut ohne Code ändern zu müssen.
Wie sind wir da auf MI gekommen?
-
Im Prinzip hatte ich nur gehofft dich zum nachdenken zu bewegen - hat leider nicht geklappt und du hast das alles wohl sehr persönlich genommen...
tfa schrieb:
"Beliebigen Code"? LOL. Beliebig schlechten?
Es ist also nur ein Shade-of-mine Postulat und nicht viel dahinter.Natürlich durchschnittscode. In gutem Code kommt das nicht vor - aber in gutem Code gelten die ganzen Argumente gegen MI doch sowieso auch nicht.
Ich weiß nicht mit wieviel freien Programmierern du zu tun hast - in einer geschlossenen Gruppe (zB firma) kann man sich ja aussuchen was man dort haben will - aber wenn du dir einen Java Entwickler einkaufst kannst du locker schonmal 50% mit solchem Code erwischen und aussortieren.
Es ist halt ein Fakt dass Java Interfaces zu tieferen Hierachien führen als man ohne sie hätte. Schau dir zB eine C++ library an, man hat idR sehr flache hierachien und schmale. In Python hat man zB noch deutlich schmalere. In Java dagegen eher tiefe und vorallem breite.
Denn du musst sehr viele Interfaces definieren da ein nachträgliches ändern nicht gut möglich ist.
Bestes Beispiel eben die UnsupportedOperationException. Die gibt es, weil Interfaces unflexibel sind. Du kannst nicht auf nachträgliche Änderungen reagieren. Vergleiche Java Interfaces mal mit Ducktyping aus zB Python oder Templates in C++.
In vielen Sprachen sagt man "alles was sich wie ein T verhält ist ein T" in Java sagt man "alles was TAble implementiert ist ein T". Das bedeutet zB dass du nicht ein subset von T unterstützen kannst (readonly container) und dennoch kompatibel bist.
Desto komplexer die Strukturen werden desto eher kommt man in so eine Situation. Das Problem sind nämlich nachträgliche Anforderungsänderungen. Denn du kannst mit interfaces nicht nachträglich eine Operation als optional definieren. Wenn dieser Fall aber eintritt musst du zu einer UnsupportedOperation Exception greifen oder groß refactoren - und du kannst vorher nie alle änderungen kennen.
Sehr wenige Sprachen? Von den bekannten, modernen (statisch getypen) OO-Sprachen haben die meisten Interfaces (z.B. Java, C#, Delphi, D). C++ hat keine, aber C++ ist auch nicht modern.
Komisch, dass die Designer dieser neuen Sprachen dieses enorm unflexible , bescheuerte Interface-Konzept verfolgen. Wahrscheinlich sind die alle so blöd wie ich...Du weichst immer nur aus. Nenn jetzt endlich eine Sprache. Java ist ja laut dir schlecht designed (und C# und D sind nur ein abklatsch davon). Sind wir also bei Delphi gelandet?
Warum diese Sprachen interfaces haben, habe ich übrigens schon erklärt. Und du schuldest mir immer noch massig antworten
Und übrigens habe ich nie gesagt dass Java Interfaces schlecht wären - das legst du mir jetzt in den Mund. Aber macht ja nichts. Ich wollte dich ja eigentlich nur zum nachdenken anregen - hat aber leider nicht geklappt.
Java Interfaces sind ein Konzept dass technisch notwendig ist. Sie haben viele Nachteile ermöglichen aber wegen der technischen limitierung von statischer polymorphie und vererbung sachen die sonst in java nicht möglich wären. Deshalb sind sie gut. Aber vielen anderen sprachen (und C# und Co sind hier alle gleich) sind sie nicht notwendig.
Ein schönes Beispiel ist zB die .close() methode. Enorm viele Klassen bieten diese Methode an - aber es gibt kein Closable Interface dafür - obwohl es unheimlich praktisch wäre. Es gibt seit 1.5 zwar ein Interface für Streams - aber hier sieht man zB wie unflexibel interfaces sind: für semantisch ähnliche Objekte existiert es nicht. zB Sockets, Window Handles, etc. Das ist einfach unflexibel. Deshalb hilft man sich öfters auch mit Reflection die in Java zB sehr schön ist. Aber das ändert nichts daran das Interfaces eine technische notwendigkeit in java sind und keine glorreiche idee. Was man zB auch daran merkt dass eine ABC in einer MI sprache von einem interface nicht zu unterscheiden ist
Vergleiche dazu einfach nochmal folgendes:
A) Ein T ist alles was sich wie ein T verhält
und
Ein T ist alles was TAble implementiert
-
tfa schrieb:
Sehr wenige Sprachen? Von den bekannten, modernen (statisch getypen) OO-Sprachen haben die meisten Interfaces (z.B. Java, C#, Delphi, D).
Allen diesen Sprache ist gemein, daß sie keine MI haben! Man hat im Laufe der Zeit erkannt, daß SI kein gangbarer Weg ist und hat dann diese MI für Arme eingebaut. Man hat ergo einen Defekt von SI behoben. Man bekommt exakt die gleichen Nachteile zur Laufzeit, kann man die Vorteile beim Programmentwerfen aber nicht anwenden.
-
tfa schrieb:
Zu UnsupportedOperationException: Ja, die ist scheiße. Aber wer redet von Java? Wer sagt, dass die Standard-API von Java ein gutes Beispiel für Objektorientierung ist? Ganz im Gegenteil. In einem guten Design kommt man gut ohne UnsupportedOperationException aus.
Sowas ist ein Standardproblem wenn du dauernd Interfaces hast
Nein ist es nicht. Nur wenn man zu blöd ist, sie richtig einzusetzen.
Danke, danke, danke. Damit hast du für immer und ewig fricky's gegen C++ pro Java getrolle entkräftigt.
-
~john schrieb:
Allen diesen Sprache ist gemein, daß sie keine MI haben! Man hat im Laufe der Zeit erkannt, daß SI kein gangbarer Weg ist und hat dann diese MI für Arme eingebaut.
Das sagt auch nur jemand, der noch nicht ausführlicher über den C++- Tellerrand geschaut hat
@Shade: sehr schöne und treffende Ausführungen zum Thema Interfaces. Wobei anzumerken wäre, daß Mehrfachvererbung, wenn sie als "Interfaces für Reiche" mißbraucht wird, dieselben Probleme teilt.
-
audacia schrieb:
~john schrieb:
Allen diesen Sprache ist gemein, daß sie keine MI haben! Man hat im Laufe der Zeit erkannt, daß SI kein gangbarer Weg ist und hat dann diese MI für Arme eingebaut.
Das sagt auch nur jemand, der noch nicht ausführlicher über den C++- Tellerrand geschaut hat
So ein Unfug kann nur von jemanden kommen, der noch nie mit MI richtig gearbeitet hat. CLOS, Eiffel, Python haben MI; Ruby hat mixins (d.h. nicht nur Interfaces).
Ergo, außerhalb der C++ Welt existiert MI auch, und das hat auch seine OOD Gründe.
-
~john schrieb:
...Python haben MI...
aber python z.b. verwendet einen einfachen trick, indem zuerst in der ersten klasse der vererbungsliste und deren oberklasse(n) gesucht wird, dann in der zweiten usw. um namenskonflikte zu verhindern. und ich wette, die anderen von dir aufgezählten sprachen haben auch irgendwas eingebaut, um dem 'killerdiamanten' aus dem weg zu gehen.
~john schrieb:
Ergo, außerhalb der C++ Welt existiert MI auch, und das hat auch seine OOD Gründe.
du meinst wohl OOA, dabei wird die programmiersprache nicht berücksichtigt. beim OOD will man keine mehrfachvererbung (z.b. wegen der bekannten probleme) haben. beziehungen, die scheinbar wie mehrfachvererbungen aussehen, werden in irgendwas sinnvolles aufgelöst (je nachdem, was die gewählte programmiersprache hergibt).
-
aber python z.b. verwendet einen einfachen trick, indem zuerst in der ersten klasse der vererbungsliste und deren oberklasse(n) gesucht wird, dann in der zweiten usw. um namenskonflikte zu verhindern. und ich wette, die anderen von dir aufgezählten sprachen haben auch irgendwas eingebaut, um dem 'killerdiamanten' aus dem weg zu gehen.
C++ auch, was willst du also sagen?
Das Diamond Problem tritt jetzt auch nicht wirklich oft auf.. also...???
Wenn das dein einziges Argument ist, ist deine Argumentationsweise gewohnt dünn.
-
JustAnotherNoob schrieb:
C++ auch, was willst du also sagen?
ich will damit sagen, dass programmiersprachen mit mehrfachvereerbung irgendwas brauchen, um doppeldeutigkeiten zu verhindern. klar, mit c++ geht's auch, wenn man ein 'virtual' an die richtigen stellen hinfrickelt. aber fundamentale probleme der mehrfachvererbung, wie missbrauch und unnötige komplexität (mehrfachvererbung wird eingesetzt, wo eigentlich aggregation hingehört) bestehen weiterhin.
-
+fricky schrieb:
~john schrieb:
...Python haben MI...
und ich wette, die anderen von dir aufgezählten sprachen haben auch irgendwas eingebaut, um dem 'killerdiamanten' aus dem weg zu gehen.
Eine Sprache mit MI braucht eine Möglichkeit dieses Problem aufzulösen, das ist korrekt. Aber in der Realität ist das kein Problem, da ein diamond fast nie verkommt, und falls man ihn doch braucht, programmierst Du Dir bei einer Sprache mit SI einen Wolf. Das ist Gefrickel pur.
+fricky schrieb:
beim OOD will man keine mehrfachvererbung (z.b. wegen der bekannten probleme) haben.
Nein, OOD war gemeint, da man mit MI viele Dinge einfacher gestalten kann, das setzt den korrekten Gebrauch von Aggregation voraus. In SI Sprachen muß man Aggregation verwenden, weil MI nun einmal nicht möglich ist, selbst in den Fällen in denen man keinen Diamond hat. Interfaces beheben das Problem nur zum Teil, weil man wieder Angst vor der Qualität der Ausbildung von Programmierern hat.