NULL
-
~john schrieb:
Nein, es ist der einzig richtige Begriff!
[...]
Um es zu konkretisieren:
Interface Klassen sind abstrakte Superklassen ohne Implementation, und beim Ableiten dürfen keine Methodennamenskollisionen auftreten.Unfug. Vererbung setzt voraus, daß etwas vererbt wird. Interfaces implementiert man lediglich. Daß Methodennamen nicht kollidieren dürfen, ist dabei ein Artefakt der Sprache C++; in Delphi ist das beispielsweise kein Problem.
-
jein, schau mal hier: http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
Features: Multiple Inheritance
Danke dass du dir selbst widersprichst, dann muss ich das nicht mehr tun.Ach ja: Wenn es Vererbung ist von einer abstrakten Klasse mit ausschließlich abstrakten Methoden zu erben, dann ist es das auch bei Interfaces.
Dass nur das Subtyping stattfindet kann man so oder so auslegen, macht aber keinen Unterschied für den Inhalt der Diskussion.
-
audacia schrieb:
~john schrieb:
Nein, es ist der einzig richtige Begriff!
[...]
Um es zu konkretisieren:
Interface Klassen sind abstrakte Superklassen ohne Implementation, und beim Ableiten dürfen keine Methodennamenskollisionen auftreten.Unfug. Vererbung setzt voraus, daß etwas vererbt wird. Interfaces implementiert man lediglich. Daß Methodennamen nicht kollidieren dürfen, ist dabei ein Artefakt der Sprache C++; in Delphi ist das beispielsweise kein Problem.
Kennst du C++ überhaupt? Wenn man zwei mal void *doSomething(); hat, dann kollidiert da zwangsweise etwas. Sprache hin oder her. Und in C++ kann ich es leicht umgehen indem ich den Klassenname voranstelle.
In anderen Sprachen habe ich gar nicht erst diese Wahlmöglichkeit.Mir fällt gerade auf, dass man Sprachen gut mit unterschiedlichen Regierungsformen identifizieren kann. Denn je mehr Freiheiten der Bürger hat umso mündiger muss er sein damit diese Regierungsform funktioniert und umgekehrt. Passt doch perfekt zu den Freiheiten die man dem Programmierer in Sprache X erlaubt bzw. in Sprache Y verbietet.
-
Shade Of Mine schrieb:
dh in C++ ist also per definition kein vernünftiges OOP möglich...
so ist es. es gibt in wahrheit nur ein objekt, nämlich 'den speicher', in dem wilde pointer, placement-news, delete[], delete, usw. ohne rücksicht auf verluste, herumwüten können.
-
Kenner der Wahrheit schrieb:
Kennst du C++ überhaupt? Wenn man zwei mal void *doSomething(); hat, dann kollidiert da zwangsweise etwas. Sprache hin oder her. Und in C++ kann ich es leicht umgehen indem ich den Klassenname voranstelle.
In anderen Sprachen habe ich gar nicht erst diese Wahlmöglichkeit.Kennst du Delphi überhaupt?
=> Nuhr.Kenner der Wahrheit schrieb:
Mir fällt gerade auf, dass man Sprachen gut mit unterschiedlichen Regierungsformen identifizieren kann.
Dann wäre C++ wohl die Anarchie
-
JustAnotherNoob schrieb:
jein, schau mal hier: http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
Features: Multiple Inheritance
Danke dass du dir selbst widersprichst, dann muss ich das nicht mehr tun.ich schrieb 'jein', was soviel heisst wie: 'teilweise stimmts was du gesagt hast'. du betrachtest das thema nur aus einer 30 jahre alten c++ scheuklappen-perspektive (interfaces sind nichts anderes als vererbung z.b.).
-
audacia schrieb:
Vererbung setzt voraus, daß etwas vererbt wird. Interfaces implementiert man lediglich. Daß Methodennamen nicht kollidieren dürfen, ist dabei ein Artefakt der Sprache C++; in Delphi ist das beispielsweise kein Problem.
Bei Interfaces wird das Interface vererbt. Wenn dem nicht so sein würde wäre Polymorphie ziemlich witzlos.
-
Shade Of Mine schrieb:
dh in C++ ist also per definition kein vernünftiges OOP möglich, da du bei interfaces extends statt implements sagst?
Keine Ahnung, wie du jetzt darauf kommst...
OO kommt auch gut ohne Klassen und Interfaces aus, richtig. Aber "nix zu tun" ist zu viel gesagt. Die meisten OO-Sprachen unterstützen mindestens Klassen. Viele davon Vererbung. Und die lässt sich wunderbar missbrauchen.
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?[/quote]
c++ ist zB wunderbar in der hinsicht: alles was sich wie ein T verhält, ist ein T. In Java hast du plötzlich TAble als interface. *brr* (wenn du wissen willst warum *brr* dann schau dir mal UnsupportedOperationException an).
Wieder ein OO-Defizit! T ist ein Typ, TAble ist ein Typ, TImpl ist ein Typ. Was es noch alles ist, ist völlig unerheblich. Jedes Objekt muss sich so verhalten, wie es die Typen verlangen. Im Grunde ist es dir sogar verboten zu wissen, von welcher konkreten Klasse das T, TImpl oder TAble erzeugt wurde. Google mal nach "LSP", das ist wichtig. Dies gilt für statisch typisierte Sprachen. Bei dynamischen wie Smalltalk oder Ruby sind Typen wiederum irrelevant. Da gibt es nur Objekte und Messages.
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.
Oder kannst du mir den grossen unterschied einer ABC gegenüber einem Interface in einer Sprache mit MI erklären?
(und vielleicht auch noch gleich warum man in Java so oft Interface+ABC habe um eine Schnittstelle zu definieren?)Eine Schnittstelle definiert man über ein Interface. Das reicht völlig.
-
Tachyon schrieb:
audacia schrieb:
Vererbung setzt voraus, daß etwas vererbt wird. Interfaces implementiert man lediglich. Daß Methodennamen nicht kollidieren dürfen, ist dabei ein Artefakt der Sprache C++; in Delphi ist das beispielsweise kein Problem.
Bei Interfaces wird das Interface vererbt. Wenn dem nicht so sein würde wäre Polymorphie ziemlich witzlos.
Nein, ein Interface kann ein anderes Interface erweitern. Wo nichts ist, kann auch nichts vererbt werden.
-
tfa schrieb:
...Wo nichts ist, kann auch nichts vererbt werden.
Ein Interface ist aber nicht "nichts".
Ein Interface erweitert auch nichts, sondern stellt eine Verbindlichkeit dar. Dabei kann das Interface auch nichts erweitern. Es muss mindestens befriedigt werden. Das Interface kann jedoch erweitert werden.
-
tfa schrieb:
Shade Of Mine schrieb:
dh in C++ ist also per definition kein vernünftiges OOP möglich, da du bei interfaces extends statt implements sagst?
Keine Ahnung, wie du jetzt darauf kommst...
Du definierst Interfaces über implements.
Ich definiere Konzepte.Irgendwann verstehst du das auch, keine Angst.
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.
Wieder ein OO-Defizit! T ist ein Typ, TAble ist ein Typ, TImpl ist ein Typ. Was es noch alles ist, ist völlig unerheblich. Jedes Objekt muss sich so verhalten, wie es die Typen verlangen. Im Grunde ist es dir sogar verboten zu wissen, von welcher konkreten Klasse das T, TImpl oder TAble erzeugt wurde. Google mal nach "LSP", das ist wichtig. Dies gilt für statisch typisierte Sprachen. Bei dynamischen wie Smalltalk oder Ruby sind Typen wiederum irrelevant. Da gibt es nur Objekte und Messages.
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.
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?
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
Denn es macht aus stark typisierten sprachen schwach typisierte.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.
Oder kannst du mir den grossen unterschied einer ABC gegenüber einem Interface in einer Sprache mit MI erklären?
(und vielleicht auch noch gleich warum man in Java so oft Interface+ABC habe um eine Schnittstelle zu definieren?)Eine Schnittstelle definiert man über ein Interface. Das reicht völlig.
Ein Interface ist ein Interface deshalb ist es gut.
Das ist doch dumm. Du musst erklären warum ein Interface etwas anderes ist als eine ABC ohne default verhalten. Wenn du das kannst bist du gut. Aber es geht nicht. Wenn wir MI haben ist ein Interface eine ABC.
-
Oh jetzt gehts um MI, wie spannend
Zum einen, eine abstrakte Klasse mit nur abstrakte Methoden ist ein Interface, wo es kein Interfaces gibt muss halt so eine Klasse als "Interface" herhalten.
Zum anderen, MI mit nicht vollstaenigen abstrakten Klassen ist ziemlich ueberfluessig (wie vieles in C++). Sieht gut in der Theorie aus, ist aber eine Katastrophe in der Praxis. In der Praxis sollte man immer Komposition der Vererbung vorziehen, deswegen kommt man auch wunderbar ohne MI aus.In der C++ FAQ steht das uebrigens auch (ich weis zwar nicht was die Frage unter Op.Uberladung verloren hat):
http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.13Ein 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.
Zu UnsupportedOperationException, das wird ausschlieslich in dem Collection Framework verwendet und zwar dann wenn eine Liste read-only ist aber trotzdem das allgemeine List-Interface implementiert. Zum anderen ist es eine RuntimeException, d.h. wenn diese Exception fliegt, dann hast du (wie beim NullPointerException) einen schweren Fehler im Programm, der nicht von dem Compiler gedeckt werden kann. Ein Ausweg waere eine ReadOnlyList Interface und ein ReadWriteList Interface. Aber das kompliziert die Sache einfach nur, waere aber moeglich.
-
DEvent schrieb:
[...]Es ist nur noetig bei stark typesierten Sprachen, es sagt nur das eine Klasse das Interface anbietet, [...]
Nein. Interfaces haben rein gar nichts mit der Sprache zu tun. Ein Interface stellt eine Verbindlichkeit dar die besagt, dass eine Entität bestimmte Dinge anbietet. Es ist ein Konzept.
Implementiert man in nicht typisierten Sprachen gegen ein bestimmtes Interface und eine übergebene Entität bietet dieses Interface nicht an, dann bekommt man einen entsprechenden Laufzeitfehler. Ob dies Sprache hierfür nun stark oder schwach typisiert ist, spielt keine Rolle.
Templates in C++ sind auch ein gutes Beispiel, wo Interfaces unabhängig von Typen befriedigt werden müssen.
-
Tachyon schrieb:
DEvent schrieb:
[...]Es ist nur noetig bei stark typesierten Sprachen, es sagt nur das eine Klasse das Interface anbietet, [...]
Nein. Interfaces haben rein gar nichts mit der Sprache zu tun. Ein Interface stellt eine Verbindlichkeit dar die besagt, dass eine Entität bestimmte Dinge anbietet. Es ist ein Konzept.
Implementiert man in nicht typisierten Sprachen gegen ein bestimmtes Interface und eine übergebene Entität bietet dieses Interface nicht an, dann bekommt man einen entsprechenden Laufzeitfehler. Ob dies Sprache hierfür nun stark oder schwach typisiert ist, spielt keine Rolle.
Templates in C++ sind auch ein gutes Beispiel, wo Interfaces unabhängig von Typen befriedigt werden müssen.Hast recht, habe mich zu sehr auf Java versteift. Aber man braucht trotzdem keine MI
-
DEvent schrieb:
In der Praxis sollte man immer Komposition der Vererbung vorziehen, deswegen kommt man auch wunderbar ohne MI aus.
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.
ob man aber von 3 ABCs oder 3 interfaces erbt ist aber wirklich egal.
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.
aber die frage ist: meinst du mit Interface das Konzept eines Interfaces (also ==ABC) oder java interfaces?
Zu UnsupportedOperationException, das wird ausschlieslich in dem Collection Framework verwendet und zwar dann wenn eine Liste read-only ist aber trotzdem das allgemeine List-Interface implementiert. Zum anderen ist es eine RuntimeException, d.h. wenn diese Exception fliegt, dann hast du (wie beim NullPointerException) einen schweren Fehler im Programm, der nicht von dem Compiler gedeckt werden kann. Ein Ausweg waere eine ReadOnlyList Interface und ein ReadWriteList Interface. Aber das kompliziert die Sache einfach nur, waere aber moeglich.
Exakt. Das ist zB einer dieser Punkte warum man nicht gegen Interfaces sondern gegen Schnittstellen programmieren sollte. Java Interfaces sind enorm statisch und unflexibel - wie man zB hier sieht (oder an einem fehlenden Closable Interface, etc.)
-
DEvent schrieb:
Hast recht, habe mich zu sehr auf Java versteift. Aber man braucht trotzdem keine MI
Nein, brauchen tut man sie nicht. Man braucht auch keine SI, oder Hochsprachen. Man braucht auch keine interaktiven Eingabemöglichkeiten. Man könnte alles mit Lochstreifen programmieren. Oder mit Kippschaltern.
Es ist allerdings schön, wenn man Alternativen hat, wenn sie zur Vereinfachung einer Problemlösung beitragen können.
-
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.