Diskussion:Schnittstelle (Objektorientierung)

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Schnittstelle (Objektorientierung)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Kritik

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)

Vererbung und Schnittstelle

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:

1. Im Artikel steht "stellt eine Art Vererbung dar" und nicht "das ist Vererbung.", also eine Abmilderung, das sei erst mal zulässig.
2. 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.
3. 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)

GUID und IUnknown

Eine Schnittstelle wird bei COM (und Corba ?) von IUnknown abgeleitet. Damit ist auch eine Vergabe einer GUID an die Schnittstelle verbunden. Dies sollte im Artikel angesprochen werden.

Unklarer Absatz

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)

Beispiel mit IKonto

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)

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)

Artikelgliederung

"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)

Instanziierung von Interfaces?

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)

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)

Falsche Lemmabezeichnung

Der Text befasst sich ausschließlich mit der speziellen Form von Schnittstellen i.Z. mit der Objektorientierung, das Lemma heißt aber 'Schnittstelle (Programmierung)'. Da ist die OO nur eines von vielen Konzepten. In der Programmierung ist die Bedeutung von 'Schnittstelle' auch sehr viel allgemeiner. Fazit: Das Lemma sollte umbenannt werden in Schnittstelle (Objektorientierung). --VÖRBY (Diskussion) 17:30, 5. Sep. 2012 (CEST)

So ähnlich hieß das Lemma auch ursprünglich. Da einigen Leuten aber '..(Objektorientierte Programmierung)' als Lemma-Titel zu lang war, wurde einfach abgekürzt - leider dabei der Kontext vergessen. Man sollte also nochmal 'verschieben'. --VÖRBY (Diskussion) 18:23, 5. Sep. 2012 (CEST)

Und was bitte ist an deinen Benennungen besser? Der Seitentitel „Schnittstelle (objektorientierte Programmierung)“ ist gegenüber dem jetzigen „Schnittstelle (Programmierung)“ nach wie vor unnötig lang, da es keinen ersichtlichen Konflikt mit anderen Bezeichnungen gibt. Nur für dessen Unterscheidung ist aber der unschöne Klammerzusatz gedacht (siehe auch „Schnittstelle“ – was nebenbei bemerkt wohl besser mal eine richtige BKL(-Seite) werden sollte). Und „Schnittstelle (Objektorientierung)“ beschränkt den Seitentitel nur unnötig auf die einseitige Objektorientierung (oder OO :-) ), wie du es selbst schon genannt hattest. --92.226.60.139 18:47, 5. Sep. 2012 (MESZ)

'Schnittstelle(O.O.P)' hieß der Artikel früher mal. Da war er wenigstens korrekt. Nur Titelkürzungen mit Sinnveränderung sind aber inkorrekt. Der Inhalt bezieht sich nun mal ('einseitig') auf die OO, dann soll er das auch im Titel zeigen. Allerdings: Ob hier die Bezeichnung 'Schnittstelle ...' überhaupt klug gewählt ist, bezweifle ich. Da werden Regeln und Gegebenheiten beschrieben, die nur im weitesten Sinn als 'Schnittstelle' (i.S. von 'Stelle = Ort') bezeichnet werden können. Ein OO-Profi könnte vielleicht eine bessere Bezeichnung finden..

Ob Schnittstelle eine BKL sein sollte, ist eine andere Frage. Jedenfalls verweist dieses Lemma bereits auf eine Reihe spezieller Bedeutungen. --VÖRBY (Diskussion) 19:10, 5. Sep. 2012 (CEST)

Die Diskussion ist überflüssig. Das Pendant Klasse steht ja auch mit dem Suffix "Programmierung" da. Außerdem lassen sich die Vorzüge eines Interfaces auch in prozeduraler Programmierung benutzen. --Nightfly | _Disk 10:06, 6. Sep. 2012 (CEST)

Wenn anderes Lemmas falsche Bezeichnungszusätze tragen, muss das keine Rechtfertigung für diesen Fall hier sein. Doch immerhin gibt es den Begriff 'Klasse' (in der Programmierung) i.W. nur im Rahmen der OOP - im Gegensatz zu 'Schnittstelle'. Die 'Vorzüge eines Interfaces' sind unbestritten, nur behandelt sie der Artikel nicht, sondern bezieht sich zu 95% auf Sachverhalte aus der OO. Bin also nach wie vor der Meinung, ein Rename wäre erforderlich - vielleicht nur mit '(OOP)', vielleicht auch ohne 'Schnittstelle'. --VÖRBY (Diskussion) 10:42, 6. Sep. 2012 (CEST)

Andere Lemma-Benennungen als untauglich abzustempeln ist genausowenig ein Grund, eine Lemma-Umbenennung zu rechtfertigen. Warum also krampfhaft eine Lemma-Änderung herbeidiskutieren, obwohl der Zusatz "(Programmierung)" nicht falsch ist? Fakt ist, dass Interfaces im Rahmen der Benutzung nicht zwingend was mit OOP zu tun haben müssen. Daher wäre dein Zusatz sogar falsch. --Nightfly | _Disk 12:05, 6. Sep. 2012 (CEST)

Jetzt lies nur mal die Einleitung. Wo steht da was von allgemein in der Programmierung benutzbaren Interfaces? Dort und im weiteren Artikel werden nur Spezialsachverhalte i.Z. mit der OOP behandelt; ich hoffe, du verstehst was davon. Da ist nichts 'krampfhaftes' dabei, die Bezeichnung ist einfach falsch bzw. hochgradig unpräzise. Wenn 'man' den Artikel umschreiben würde, könnte die Überschrift natürlich passen. Aber wer tut das? Und wohin käme dann der derzeitige Text? Die Änderung auf '(Programmierung)' erfolgte m.E. ausschließlich aus der Zielsetzung heraus, eine kürzere Überschrift zu haben - die aber nicht mehr dem Inhalt entspricht. --VÖRBY (Diskussion) 12:38, 6. Sep. 2012 (CEST)

Ja, ich denke, ich darf mich "vom Fach" nennen. Nur weil eine Nutzung bei prozeduraler Programmierung nicht im Artikel erwähnt wird, bedeutet das doch nicht, dass das Lemma zu unpräzise ist? Was ist, wenn sich jemand dazu entscheidet, diesen Sachverhalt in den Artikel einzubringen? Muss dann das Lemma erneut verschoben werden? Dann lieber gleich richtig. Das Suffix "(Programmierung)" entstand zwar aus Gründen der Lemma-Länge, aber auch, da dies die korrekte "Oberkategorie" für dieses Thema ist. --Nightfly | _Disk 15:16, 6. Sep. 2012 (CEST)

Lieber NIGHTFLY, der Artikel ist ja gut; er beschreibt in hervorragender Qualität Sachverhalte aus der OOP.
> Ob diese Sachverhalte in der OOP überhaupt und offiziell mit dem Begriff 'Schnittstelle' benannt werden, weiß ich nicht; jedenfalls erwähnt der Artikel OOP dieses Wort nicht als spezifischen Ausdruck, sondern einfach mal so als 'Schnittstellen der Objekte' usw. Insofern könnte hier auch eine andere OOP-bezogene Überschrift (anstatt 'Schnittstelle') besser passen. Zum Vergleich könnte man auch Artikel mit der Bezeichnung 'SS (Betriebssystem)', 'SS (Drucker)', 'SS (SQL)', 'SS (Internet)' u.v.a. einstellen, weil alle 'Systeme' über Schnittstellen miteinander kommunizieren, das ist 'selbstverständlich' und 'begriffsimmanent'.
> Ich denke, neben diese ausführlichen, auf OOP ausgerichteten Texte würde eine Beschreibung für 'SS (Programmierung (allgemein))' in denselben Artikel nicht passen: Weil das ein ganz anderer Begriff (siehe dort) wäre, müsste das auch ein anderes Lemma sein. Davon abgesehen täte man sich auch schwer, ein solches Lemma zu beschreiben - weil es, verglichen mit dieser OOP-Beschreibung, in der Programmierung unzählige weitere (Arten von) Schnittstellen gibt.
> Die 'Oberkategorie' darf sich niemals im Lemma-Titel finden ('siehe Normalisierung), sondern muss über die 'Kategorie' angewählt werden - was mit 'Kat:OOP' auch (richtig) eingestellt ist: Diese gehört letztlich zur 'Oberkategorie Programmierung'.

Ich möchte keine weiteren Mega-Diskussionen führen und schlage deshalb vor, den Stand der Diskussion in die QS zu geben; dort kann dieser (formale) Aspekt 'passt die Überschrift zum Inhalt?' geprüft und entschieden werden. Meine Zusammenfassung dazu wäre (neben den oben fett gedruckten Argumenten):

• Werden die jetzt beschriebenen Sachverhalte in der OOP tatsächlich und explizit 'Schnittstelle' genannt? Wenn nein, wäre die Überschrift vielleicht 'TF', der Artikel sollte dann anders benannt werden.
• Wenn ja: Passt der jetzige Titel zum Inhalt? Wenn diese Frage mit 'ja' beantwortet wird, dürfte ein fiktiver Artikel 'Österreich' zu 95% aus 'Wien' beschreibenden Texten bestehen. ;-)
• Wenn nein: Sollte man den Artikel 'SS (OOP)' oder 'SS (Objektorientierung)' nennen?

Oder wir können uns auf die Verschiebung HIER einigen. Bitte nochmal kurze Antwort dazu. Danke. --VÖRBY (Diskussion) 18:57, 6. Sep. 2012 (CEST)

Ich kann dir nicht ganz folgen. Natürlich ist das, was hier im Artikel behandelt wird, eine Schnittstelle. Was soll es sonst sein? Das ganze als TF zu titulieren, grenzt an fehlende Fachkenntnis. Also, ich beharre darauf, dass das Lemma so bleiben soll, wie es ist: Mit dem Suffix "(Programmierung"). Objektorientierte Programmierung ist Programmierung - also ist schon alles ganz korrekt hier. --Nightfly | _Disk 19:18, 6. Sep. 2012 (CEST)

Klar ist das 'eine Schnittstelle' - wie tausend andere auch. Und 'Wien' ist 'Österreich'. Ich fordere also eine QS an. --VÖRBY (Diskussion) 19:26, 6. Sep. 2012 (CEST)

siehe dazu Wikipedia:Redaktion Informatik/Qualitätssicherung#Schnittstelle (Programmierung) --Sebastian.Dietrich  ✉ 16:13, 9. Sep. 2012 (CEST)

Der Artikel wurde (nach erfolgter QS-Diekussion) heute per 'Verschieben' von 'Schnittstelle (Programmierung)' in 'Schnittstelle (Objektorientierung)' umbenannt. Dabei wurde eine Weiterleitungsseiter für das alte Lemma angelegt.

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 10:16, 10. Sep. 2012 (CEST)

Interfaces Sinnvoll

"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:

1. 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.
2. 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).
3. 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)