Diskussion:Schnittstelle (Objektorientierung)

message: Meiner Ansicht nach ist ein Interface bzw. eine Schnittstelle keine spezielle Form der Mehrfachvererbung. Es wird überhaupt nichts vererbt dabei!
Ein Interface ist das aequivalent einer Spezifikation. D.h. Klassen, welche eben NICHT voneinander abhängen, können mit Hilfe eines Interfaces eine 'ist eine' (is a) Beziehung aufbauen.
Dies wird ermöglicht, weil Klassen, welche die Spezifikation erfüllen (also das Interface implementieren) via Schnittstellenname angesprochen werden können. Dabei stehen dann dem Aufrufer nur die Fähigkeiten der in der Schnittstelle spezifizierten Funktionen zur Verfügung.
Ein Interface darf somit NICHT mit irgend einer Art der Vererbung verglichen werden.
--Reto.koenig 14:11, 26. Sep 2004 (CEST)
thread_title:  Kritik 

message: Wie mein Vorredner widerspreche ich der Aussage: "Das implementieren einer Schnittstelle stellt eine Art Vererbung dar".
a) Vererbung bedeutet die Generalisierung und Spezialisierung von Klassen-Eigenschaften.
b) Eine Schnittstelle spiegelt dagegen einen Kontrakt zwischen zwei Klassen wider.
Beispiel:
zu a)
Die Klassen Frau und Mann sind Spezialisierungen der generalisierten Klasse Mensch. Sie erben die menschlichen (also gleichen) Eigenschaften Auge, Nase, Arm, Bein und erweitern/spezialisieren die unterschiedlichen Eigenschaft z.B. "Kinder gebären" und z.B. "Samen erzeugen".
zu b)
Die Klasse Mann kann nun verschiednen Schnittstellen haben und am besten läßt sich das über das sogenannte Rollenkonzept erklären. Welche Rollen, in welchen Beziehungen (Kontrakten) nimmt z.B. der Mann an oder in OO-Stil ausgedrückt, welche Schnittstellen implementiert der Mann?
z.B. Schnittstelle a: Ehemann, Schnittstelle b: Vorgesetzer, Schnittstelle c: Liebhaber.
In jeder Schnittstelle kann ein unterschiedlicher Satz von Eigenschaften der Klasse Mann offengelegt werden.
XLXP.de
:Widerspruch: 
:#Im Artikel steht "stellt eine Art Vererbung dar" und nicht "das ist Vererbung.", also eine Abmilderung, das sei erst mal zulässig. 
:#In der technischen Realisierung in C++ werden Schnittstellen genauso behandelt wie alle anderen Basisklassen, dort ist es unmittelbar Vererbung. Allerdings: das ist ein praktischer Aspekt, Schnittstellen werden dort über Vererbung realisiert, was noch nicht heißt, Schnittstellen sind Vererbung (aus theoretischer Sicht), aber die Aussage stellt eine Art Vererbung dar ist dort war.
:# Schnittstellen sind eine Vererbung von Pflichten. Bei Schnittstellen gilt wie bei allen anderen Basisklassen die IS-A -Relation von abgeleiteter (hier implementierender) Klasse zu Basisklasse (hier: Schnittstelle.). Aus dieser Sicht ist eine Schnittstelle eine Art der Vererbung. Direkt und unmittelbar. Vererbung kann man sehen als Vererbung von Möglichkeiten (bedeutet: abgeleitete Klasse kann alles, was Basisklasse kann), aber auch als Vererbung von Pflichten (bedeutet: abgeleitete Klasse realisiert alles, was Basisklasse erfordert). Lezteres (Vererbung von Pflichten) ist ein Teilaspekt von  abstrakten Klassen, bei Schnittstellen ist es der gesamte Aspekt. Gerade die Vererbung von Pflichten ist meist ein wichtiger Aspekt der Vererbung überhaupt. Die Vererbung von Möglichkeiten ist im ersten Ansatz oft naheliegend, führt aber oft zu falschen Strukturen. Beispiele dazu gibt es in der Literatur.
:ergo: "stellt eine Art Vererbung dar" sollte im Artikel stehenbleiben, vielleicht kann man das im Sinne der Vererbung von Pflichten sogar noch stärker ausbauen.
:Ein anderes anliegen: Schnittstelle versus abstrakte Klasse: In der Java-Programmierung ist der Unterschied klar. In C++ tendieren einige Programmierer dazu, keine reinen Schnittstellen (rein abstrakte Klassen) zu formulieren, sondern (weil's einfach geht) immer noch was anderes hineinzutun, ein paar Attribute, statische Methoden. Die reine Form der Schnittstelle wie sie in Java syntaktisch erzwungen wird, wird hier ignoriert. Ich suche nach der Argumentation, warum man auch in C++ nur reine abstrakte Methoden und nichts anderes in Schnittstellen-Klassen hineintuen sollte. Die Argumentation, "die Java-Entwickler haben sich dabei was gedacht, und man kommt gut damit zurecht" ist eingefleischten C++-lern leider nicht beizubringen. Kann da jemand helfen? --HartmutS 19:39, 23. Apr 2006 (CEST)
thread_title:  Vererbung und Schnittstelle 

message: :Später kann man dann durch Zugriff über diese Schnittstelle sicherstellen bzw. garantieren, dass die Methode existiert. Neben der Implementation in Klassen, kann eine Schnittstelle auch in abstrakte Klassen implementiert werden (somit besitzen alle Unterklassen der abstrakten Klasse die durch das Interface definierten Methoden). Weiterhin kann ein Interface ein anderes beerben. Das entstehende Interface enthält die Signaturen des beerbten Interfaces und kann weitere definieren.
Verschiedene Probleme:
* erster Satz: völlig unklar; wie soll durch die Verwendung einer Schnittstelle sichergestellt werden, dass eine Methode "existiert"? Gemeint ist wohl, dass die Methode definiert sein muss, um dem Interface zu genügen - das sollte aber deutlich anders ausgedrückt werden
* zweiter Satz: 'abstrakte Klassen' sind auch Klassen, daher ist die Unterscheidung in dieser Form unsinnig; weiterhin werden Interfaces erst durch konkrete Klassen 'implementiert'/realisiert
* letzter Satz: gemeint ist wohl 'vereint' statt 'enthält'?
* allgemein: Bezug zur Semantik fehlt in dem Abschnitt vollständig
132.230.97.10 14:28, 6. Mär 2006 (CET)
thread_title:  Unklarer Absatz 

message: Meiner Meinung ist dieses Beispiel nicht gut. Wenn es um Konten geht, dann klingt das eher nach Vererbung, nicht nach Schnittstellen. Ich glaube, es ist besser, hier eine Schnittstelle zu verwenden, die ein Adjektiv im Namen enthält. Ist mir klar, dass das keine Bedingung für Schnittstellen ist, aber es macht es einfacher zu verstehen. Wie wäre es z.B. mit IComparable? Ist ein wenig allgemeiner. 80.122.38.210 15:51, 3. Apr 2006 (CEST)
replies: text: Ich meine, das Beispiel ist gut. IKonto stellt ein Interface zu einer Kontoverwaltung dar, unter anderem um mit einer Methode den Kontostand abzufragen. Beispiele mit Kontenverwaltungen werden häufig zur Illustration in der OO verwendet. IComparable wäre eher informatiktheoretisch, weniger illustrativ. IMHO IKonto-Beispiel stehenlassen. --HartmutS 19:58, 23. Apr 2006 (CEST)
thread_title:  Beispiel mit IKonto 

message: "können Interfaces verwendet werden um Kompatibilitäten zwischen Klassen zu definieren" - die Benennung von Möglichkeiten wie man tricksen kann, im einleitenden Abschnitt (Stand 2006-04-23) missfällt mir. Die Aussage ist IMHO falsch. Die angesprochenen Kompatibiliäten sind doch genaugenommen genau das, was im ersten Satz unter gemeinsamen Signaturen deutlich benannt worden ist, und nicht irgendwelche Kompatibilitäten, bloß weil keine Mehrfachvererbung geht. Oft wird die fehlende Möglichkeit der Mehrfachvererbung in Java als Nachteil empfunden, man kann aber auch sehr oft Hinweise lesen, dass die Vererbung allzu leichtfertig eingesetzt wird, stattdessen ist eine Assoziation von Klassen oft der richtigere Weg; Es gibt auch viele Hinweise dazu, das Mehrfachvererbung auch in C++ problematisch ist. Das Thema gehört aber nicht in diesen Artikel, sondern eher zum Artikel Vererbung.
Was wird in der OO unter Interfaces verstanden, was und wie bildet davon die stark OO-angelehnte Sprache Java davon ab, was und wie bilden andere Sprachen ab (Smalltalk, C#). Das wäre Inhalt des ersten Abschnittes. Dazu gehört als Unterabschnitt das IKonto-Beispiel.
Ein weiterer Abschnitt könnte sich dann mit Interfaces in Middleware beschäftigen. --HartmutS 20:17, 23. Apr 2006 (CEST)
thread_title:  Artikelgliederung 

message: Java hat den Vorteil gegenüber .NET-Sprachen, dass ein Interface nicht in einer Klasse implementiert werden muss, um instanziert zu werden mit dem nachfolgendem Beispiel ist technisch falsch. Das Beispiel ist ein unabhängig vom Interface mit Java formulierbares Konstrukt, um eine namenlose abgeleitete Klasse zu bilden, die genau einmal instanziiert wird. Man kann dieses Konstrukt natürlich dazu nutzen, um eine Instanz zu bilden, die nur von einem Interface abgeleitet ist. Damit ist aber nicht das Interface instanziiert sondern die namenlose abgeleitete Klasse. Die Klassendefinition steht hinter dem new Name() in den {...}. Das ist natürlich ein interessantes Beispiel wie man in Java mit Interfaces umgehen kann. - Ein Interface kann man grundsätzlich nirgends niemals direkt instanziieren, das ist eine grundlegende sprachunabhängige so gewollte Eigenschaft. Insgesamt wäre am Artikel einiges zu verbessern. Ich bin zurzeit gerade nur beim surfen, wo ich mich einbringen könnte. --HartmutS 22:23, 1. Apr. 2007 (CEST)
replies: text: Genau genommen wird in dem von dir bemängelten Beispiel eine sogenannte anonyme innere Klasse definiert, die die Schnittstelle implementiert. Ich habe das umformuliert. Schau mal drauf, ob’s jetzt besser ist. Was wäre denn sonst noch zu verbessern? --jpp ?! 18:30, 2. Apr. 2007 (CEST)
thread_title:  Instanziierung von Interfaces? 

message: "Schnittstellen sind besonders dann sinnvoll, wenn es mehr als eine Implementierung gibt, sodass die implementierenden Klassen ohnehin mit Präfixen und Suffixen benannt werden."
Der Satz ist sehr zweifelhaft. weil:
# Schnittstellen sind IMHO auch sinnvoll wenn es nur eine Implementierung gibt. Wenn deine Klassen keine Interfaces haben wirst du in vielen Fällen verzweifeln, wenn du eine möglichst hohe Unittestabdeckung erreichen willst.
# er impleziert, dass die Klassen und das Interface gleich heißen und eines davon Prä- oder Suffixe haben. Was bei einer 1:1 Relation ja noch Sinn macht (Also IMyInterface und MyInterface). Wenn eine 1:n Beziehung besteht, heißen die Klassen oft ganz anders als die Schnittstelle. Besonders wenn man mehrere Interfaces implementiert wird das sehr deutlich. Praktisch keine der Klassen die IDisposable oder ICollection in C# implementiert heißt auch so (oder auch nur ähnlich).
# Gerade wenn die Klassen irgendwie heißen und kein direkter Bezug zum Interface hergestellt werden kann ist es praktisch am Namen zu erkennen, dass es sich um ein Interface handelt. Immerhin kommt man dann nicht auf die Idee ein Objekt davon mit new anzulegen oder zur Definition zu springen um mehr über die Implementierung herauszufinden.
Ich schlage vor den Satz zu löschen. Madame Zeena (Diskussion) 15:54, 11. Jul. 2022 (CEST)
thread_title:  Interfaces Sinnvoll