NULL
-
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.