NULL
-
+fricky schrieb:
~john schrieb:
+fricky schrieb:
wer redet hier von vererbung (ausser dir)?
Interfaces sind Mehrfachvererbung ohne Implementation. Wenigstens soviel sollte man wissen.
mehrfachvererbung ist eigentlich der falsche begriff dafür,
Nein, es ist der einzig richtige Begriff!
Mehrfachvererbung heißt erstmal nur, daß eine Klasse von mehreren Klassen abgeleitet ist, Diamonds müssen gar nicht vorkommen. Sprachen mit Interfaces lösen das Problem des Diamonds mittels der Einschränkung, daß jede Interfaces Klasse eine Superklasse sein muß. Dazu kommen üblicherweise noch Einschränkungen, daß die verschiedenen Mutterklassen einer konkreten Klasse niemals die gleichen Methodennamen verwenden dürfen. Aus diesen beiden Gründen braucht man auch kein Mittel Nameskonflikte lösen zu können. C++ hat diese Mittel, aber man braucht sie wirklich sehr selten. Sollte man Mehrfachverbung im Sinne von Interface Klassen benutzen braucht man sie gar nicht.Um es zu konkretisieren:
Interface Klassen sind abstrakte Superklassen ohne Implementation, und beim Ableiten dürfen keine Methodennamenskollisionen auftreten.
-
~john schrieb:
+fricky schrieb:
~john schrieb:
+fricky schrieb:
wer redet hier von vererbung (ausser dir)?
Interfaces sind Mehrfachvererbung ohne Implementation. Wenigstens soviel sollte man wissen.
mehrfachvererbung ist eigentlich der falsche begriff dafür,
Nein, es ist der einzig richtige Begriff!
völlig falsch klingt er, allein schon wegen des 'mehrfach' da drin. ich würde es vielleicht als 'schnittstellenbeerbung' bezeichnen. aber egal...
-
völlig falsch klingt er, allein schon wegen des 'mehrfach' da drin. ich würde es vielleicht als 'schnittstellenbeerbung' bezeichnen. aber egal...
hä?
Schau dir doch einfach an was Interfaces sind.. von der Funktionalität gekürzte Klassen, von denen man unbeschränkt erben kann.
Der letztere Fakt ist Mehrfachvererbung, nur eben ohne die Probleme dieser zuzulassen(du kannst es auch gerne anders nennen, aber durch Nomenklatur ändert sich die Semantik nicht).
Dass du in C++ auch problemlos auf Mehrfachvererbung verzichten kannst oder Klassen wie Interfaces verwenden kannst ignorierst du gekonnt. Genau wie die Tatsache, dass Mehrfachvererbung nicht nur Probleme hervorruft, sondern auch nützlich ist. Du kannst auch nicht sagen, dass die Probleme die Nützlichkeit aufwiegen, weil du es nunmal nur dann verwendest, wenn es auch wirklich nützlich ist.
Auch hier: Du verwendest es nicht aus Versehen, Fehler treten zusätzlich noch zur Compiletime auf => sinnlose Beschränkung.
-
JustAnotherNoob schrieb:
Schau dir doch einfach an was Interfaces sind.. von der Funktionalität gekürzte Klassen...
jein, schau mal hier: http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
http://mindprod.com/jgloss/interfacevsabstract.htmlJustAnotherNoob schrieb:
Dass du in C++ auch problemlos auf Mehrfachvererbung verzichten kannst oder Klassen wie Interfaces verwenden kannst ignorierst du gekonnt.
hab' ich doch gar nicht. in C++ kann man sich die abenteuerlichsten konstrukte bauen. das sowas nicht geht, würde ich niemals anzweifeln. (z.b. diese sache von vorgestern, klassen die mit hilfe der operatorüberladung pointer vorgaukeln können, usw.).
-
+fricky schrieb:
jein, schau mal hier: http://java.sun.com/docs/books/tutorial/java/concepts/interface.html
http://mindprod.com/jgloss/interfacevsabstract.htmlInterfaces sind abstrakte Klassen leicht abgewandelt.
das merkt man zB auch schon daran dass man sehr oft interface + abstrakte Klasse in Java implementieren muss wenn man nur eine Schnittstelle anbieten will.
Weil Interfaces eben einen Bereich abdecken und abstrakte Klassen einen Bereich abdecken und dieser Bereich überschneidet sich größtenteils.
Schauen wir uns dazu mal den einen Link von dir an
When To Use Interfaces
An interface allows somebody to start from scratch to implement your interface or implement your interface in some other code whose original or primary purpose was quite different from your interface. To them, your interface is only incidental, something that have to add on to the their code to be able to use your package.
When To Use Abstract classes
An abstract class, in contrast, provides more structure. It usually defines some default implementations and provides some tools useful for a full implementation. The catch is, code using it must use your class as the base. That may be highly inconvenient if the other programmers wanting to use your package have already developed their own class hierarchy independently. In Java, a class can inherit from only one base class.Ah, eine abstrakte Klasse bietet mehr Struktur? Dass es in Java unpraktisch ist von einer Klasse zu erben ist eben wegen der dummen single inheritance idee notwendig. Aber wenn ich von unendlich vielen Klassen erben kann dann bleibt da nur stehen: "An abstract class, in contrast, provides more structure."
Big deal...
Single Inheritance gibt es übrigens aus einer technischen notwendigkeit: object ist die basisklasse und wenn es mi geben würde, hätte man automatisch deadly diamonds of death. deshalb hat man interfaces als alternative zu abstrakten klassen genommen und sie halt um ein paar passende features erweitert.
dennoch hat man damit lediglich den deadly diamond eliminiert (was natürlich praktishc ist, keine frage) aber alle anderen probleme von mi hat man dennoch.
-
Shade Of Mine schrieb:
deadly diamonds of death
Indiana Shade und der tödliche Diamant des Todes
-
Warum geilen sich alle an dieser dämlichen Vererbung auf? Wofür glaubt ihr, ist die gut? Um Code wiederzuverwerten? Und wenn ich Code aus vielen Klassen wiederverwerten will, nimmt man Mehrfachvererbung? Toller Plan.
In guten OO-Designs findet Vererbung so wenig wie möglich statt, Mehrfachvererbung schon gar nicht. Programmierung gegen Schnittstellen, Komposition und Delegation ist angesagt. Das fördert Kapselung und reduziert Kopplung - im Gegensatz zu Subklassen. Interfaces ist das, was man braucht, und vielleicht 1-2 Vererbungshierarchien für die Implementierungen - wenn überhaupt.Eine anständige OO-Denkweise scheint im C++-Millieu nicht besonders weit verbreitet zu sein.
-
tfa schrieb:
Programmierung gegen Schnittstellen[...] ist angesagt. Das fördert Kapselung und reduziert Kopplung - im Gegensatz zu Subklassen. Interfaces ist das, was man braucht,
Auch wenn du implements statt extends sagst, ist und bleibt es vererbung
Und OOP hat mal überhaupt nix mit Klassen und Interfaces zu tun.
-
Shade Of Mine schrieb:
Auch wenn du implements statt extends sagst, ist und bleibt es vererbung
Nein, ist es nicht
Und OOP hat mal überhaupt nix mit Klassen und Interfaces zu tun.
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. Besonders die ach so tolle Mehrfachvererbung.
-
tfa schrieb:
Shade Of Mine schrieb:
Auch wenn du implements statt extends sagst, ist und bleibt es vererbung
Nein, ist es nicht
dh in C++ ist also per definition kein vernünftiges OOP möglich, da du bei interfaces extends statt implements sagst?
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?
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).
In C++ kann ich über extends genauso dumme hierachien erstellen wie man sie in Java hat - ob implements oder extends verwendet wird ist komplett egal.
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?)Kleiner Tipp: es liegt an der technischen notwendigkeit wegen Object als ultimative Basisklasse. Und aus der Not versucht man eine Tugend zu machen. Interfaces sind ja nichts schlechtes - nur sollte man wissen dass ein implements genauso eine Bindung wie ein extends ist. (wobei dank UnsupportedOperationException ist das in Java ja gut umgehbar...)
-
~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.