Schon wieder: Warum Interfaces

[Ghostwalker]

Hab grad die letzen Beiträge hier im Thread gelsen...uijuiui....

Also..mal gaaanz locker bleiben

Da auch einiges an Begriffen (imho) durcheinander gewürfelt wird, hier mal (nach besten Wissen) die Definitionen dafür, wie sie mir bekannt sind und von unterschiedlichster Seite auch so bestätigt wurde:


OOP:
Die logische Weiterentwicklung der Prozedurealen Programmierung (Erfinder: Prof. N.Wirt), in
dem man Daten und die Prozeduren, die diese Daten manipulieren, zu einer Einheit zusammenfasst.
Vererbung, Polymorphy usw. sind alle Teil dieses Konzepts. Erfinder ist ebenfalls Prof. N.Wirt
(siehe Oberon/Smalltalk)


Interfaces:
Interfaces sind Regeln, welche Methoden und Eigenschaften eine Klasse, die dieses Interface
unterstützen möchte, mindestens Implementieren muss. Ich kann nicht sagen, wers erfunden
hat,(nein...nicht die Schweizer von Rikola) aber da die Verbreitung von Interfaces insbesondere
durch COM/ActiveX zeitlich in den gleichen Rahmen fällt, vermute ich mal MS dahinter.


Vorteile von Interfaces:

- Übersichtlichkeit

Insbesondere wenn man mit vielen verschiedenen Klassen hantiert, erleichtern Interfaces
den Überblick zu behalten. Auch bei Teams sind Interfaces recht nützlich, da Programmierer
A nur über das Interface einer Klasse bescheid wissen muss, die Programmierer B grad baut.

- Sprachunabhängigkeit

Als "Anwender" ist mir egal, ob die Implementierung einer Interface-Klasse jetzt in C, C++ ,
Brainfuck oder was auch immer geschrieben ist, noch nicht einmal die Implementierung ist
relevant. Den "Anwender" interressieren nur die Methoden und Eigenschaften des Interfaces.


Nachteile:

- Mehr Code

Da ich die Interfaces ja irgendwo definieren muss, wird zusätzlicher Code notwendig.

- Mehr Fehlerquellen

Zumindest bei den COM-like Interfaces, wg. Referenzzählung und automatischer Freigabe.


Ob man nun auf Interfaces setzt oder nicht, muss jeder selbst entscheiden. In manchen Fällen gehts
nicht anders (Stichwort Mehrfachvererbung in Delphi). Man sollte sich aber immer bewust sein, da man sich mit den Vorteilen auch immer Nachteile einhandelt

[frapo]

Zitat von Ghostwalker:

Hab grad die letzen Beiträge hier im Thread gelsen...uijuiui....

Also..mal gaaanz locker bleiben

Da auch einiges an Begriffen (imho) durcheinander gewürfelt wird, hier mal (nach besten Wissen) die Definitionen dafür, wie sie mir bekannt sind und von unterschiedlichster Seite auch so bestätigt wurde:

Das geht mir schon die ganze Zeit so. Siehe meinen Post #54.

Zitat von Ghostwalker:

Interfaces:
Interfaces sind Regeln, welche Methoden und Eigenschaften eine Klasse, die dieses Interface
unterstützen möchte, mindestens Implementieren muss. Ich kann nicht sagen, wers erfunden
hat,(nein...nicht die Schweizer von Rikola) aber da die Verbreitung von Interfaces insbesondere
durch COM/ActiveX zeitlich in den gleichen Rahmen fällt, vermute ich mal MS dahinter.

Zumindest bei den COM-like Interfaces, wg. Referenzzählung und automatischer Freigabe.

Auch hier wird meines Wissens nach der Begriff Interface nicht im Sinne der OOP angewandt. COM/ActiveX klingt doch einfach schon zu konkret. Der Begriff Interface wird hier eher aus technischer Sicht gesehen (also das Wie und nicht das Was).

In der OOP ist der Begriff Interface doch eher konzeptionell gemeint, also ohne konkrete technische Abbildung.

Drum hatte ich ja in Post #54 auch Links gepostet, die etwas Konkretisierung in das Konzept bringen könnten.

Interfaces sind aus OOP Sicht Vereinbarungen, Regeln, Verhalten, die eine implementierende Klasse einhalten muss. Dabei ist das "wie" egal, Hauptsache die Implementierung entspricht den Vorgaben. Dadurch werden die implementierenden Klassen in gewisser Hinsicht ja auch austauschbar, Stichwort Polymorphie(Vielgestaltigkeit).

Interfaces sind auch keine abstrakte Klassen, dass ist ja auch der Grund warum sie nicht zum Klassen-/Vererbungsbaum gehören. Von daher "verbietet" es sich schon konzeptionell Interfaces als Weg für die Mehrfachvererbung zu sehen.
Sprachen die Mehrfachvererbung zulassen, bietet dafür schließlich Konzepte an.

[Sailor]

Gehen wir mal so 40 Jahre zurück. Da wurde neben dem Modulkonzept das Prinzip Information Hiding (heutzutage Encapsulation, Kapselung genannt) propagiert. Der Verwender einer Komponente (ich will hier nicht Objekt sagen, um keine Verwirrung zu stiften) sollte nur noch über Funktionen/Prozeduren auf deren Funktionalität zugreifen dürfen, ohne darüber informiert zu werden, wie diese Funktionalität realisiert worden ist. Warum das? Nun, neben den öffentlichen Eigenschaften kann eine Implementierung zusätzliche, nur ihr zukommende Eigenschaften haben. Der clevere Programmierer nutzt die natürlich. Da helfen keine Verbote. Und wenn jetzt aus irgendwelchen Gründen was geändert werden muß, dann ist diese implizite Eigenschaft möglicherweise weg, eventuell mit katastrophalen Folgen. Um das zu vermeiden, ist Kapselung eines der Grundprinzipien der OOP geworden. Leider ist in den gängigen OOP-Sprachen die konsequente Trennung von Interface und Realisierung aus mir unerfindlichen Gründen "vergessen" worden. In Delphi sind zwar zarte Versuche in dieser Richtung zu erkennen. Man hätte aber z. B. Interface und Implementation auf 2 Dateien aufteilen müssen. Und in einem Interface dürfen nur die öffentlichen Funktionen/Prozeduren auftauchen. Alles andere wie Felder oder private Funktionen gehören in die Implementation. Und von C# oder Java will ich gar nicht erstreden, die haben das ganz fallengelassen. Und so weiß der Anwender immer noch, wie es gemacht wurde. Offensichtlich haben sich einige daran erinnert, daß das eigentlich verhindert werden sollte und das meines Wissens von COM herrührende Interface umgebogen, um dem Mangel abzuhelfen und stoßen nun kräftig ins Horn. Kann man machen, aber ob das zu besser lesbaren Programmen führt, wage ich zu bezweifeln. Auch die Themen Vererbung/Mehrfachvererbung, Parametrisierung von Klassen, Benutzung unterschiedlicher Implementierungen einunddesselben Interfaces in einem Programm sollten besser innerhalb einer OOP-Sprache gelöst werden.
Fazit: Ich verwende (COM-)Interfaces zur Realisierung von OOP-Interfaces nur dort, wo es angeraten erscheint, die Interna einer Implementierung vor dem Nutzer einer Klasse zu verbergen, mangels geeigneter Sprachkonstrukte. Aber vielleicht sehen wir in naher Zukunft ein Delphi 2.0, in dem das in aller Schönheit vorhanden ist.

[frapo]

Zitat von Sailor:

Gehen wir mal so 40 Jahre zurück. Da wurde neben dem Modulkonzept das Prinzip Information Hiding (heutzutage Encapsulation, Kapselung genannt) propagiert.

Lass uns ruhig so mutig sein, 50 Jahre zurück zu gehen. Simula67 gilt, so weit ich weiß, als erste Sprache die OOP-Konzepte wie new, class und so eingeführt hat. Wie der Name schon andeutet, passierte das in den 60ern, also noch vor Pascal, Modula2 oder Oberon.. von Smalltalk mal gar nicht zu sprechen.

Zitat von Sailor:

Der Verwender einer Komponente (ich will hier nicht Objekt sagen, um keine Verwirrung zu stiften) sollte nur noch über Funktionen/Prozeduren auf deren Funktionalität zugreifen dürfen, ohne darüber informiert zu werden, wie diese Funktionalität realisiert worden ist. Warum das? Nun, neben den öffentlichen Eigenschaften kann eine Implementierung zusätzliche, nur ihr zukommende Eigenschaften haben. Der clevere Programmierer nutzt die natürlich. Da helfen keine Verbote. Und wenn jetzt aus irgendwelchen Gründen was geändert werden muß, dann ist diese implizite Eigenschaft möglicherweise weg, eventuell mit katastrophalen Folgen. Um das zu vermeiden, ist Kapselung eines der Grundprinzipien der OOP geworden.

Genau. Bei der Kapselung interessiert die konkrete Implementierung keinen.

Zitat von Sailor:

Leider ist in den gängigen OOP-Sprachen die konsequente Trennung von Interface und Realisierung aus mir unerfindlichen Gründen "vergessen" worden. In Delphi sind zwar zarte Versuche in dieser Richtung zu erkennen. Man hätte aber z. B. Interface und Implementation auf 2 Dateien aufteilen müssen. Und in einem Interface dürfen nur die öffentlichen Funktionen/Prozeduren auftauchen. Alles andere wie Felder oder private Funktionen gehören in die Implementation. Und von C# oder Java will ich gar nicht erstreden, die haben das ganz fallengelassen.

Hättest du da mal ein Beispiel? In Jave, C# und Object-Pascal(also auch Delphi) klappt die Trennung eigentlich wunderbar. Ein Interface implementiert rein gar nichts. Dort sind nur Definitionen oder Vereinbarungen beschrieben.
Die eigentliche Konkretisierung bzw. Implementierung findet in den Klassen statt, die dieses Interface auch benutzen bzw. implementieren.

Das ist ja auch der Sinn der Kapselung.

Anders Hejlsberg, der Schöpfer von Turbo Pascal, Delphi und C#, wird sich da was dabei gedacht haben sich bei der Entwicklung von Delphi und später C#, eher an Java als an C++ orientiert zu haben. Die genauen Beweggründe kannst du ja bei ihm erfragen.

Auch du wirst nicht abstreiten können, dass sein Konzept in der Fachwelt "relativ" anerkannt ist. Man durchforste einfach mal die Stellenanzeigen und den aktuellen Stand der universitären Lehre.
Funktionale Programmierung ist und war auch immer ein Thema, hat bisher aber nie die Masse erreicht.

Wenn du andere Konzepte, Ideen, Kritik vorlegen kannst, fände ich es klasse davon zu lesen, vor allem was du konkret damit meinst, das Interface und Implementierung nicht voneinander getrennt sind, in deinen Worten "vergessen" wurden.

Zitat von Sailor:

...und das meines Wissens von COM herrührende Interface umgebogen...
Fazit: Ich verwende (COM-)Interfaces zur Realisierung von OOP-Interfaces

[/QUOTE]

Und da haben wir wieder COM etc. Das hat alles erstmal nichts mit OOP zu tun!

Interface(Schnittstelle) scheint einfach ein überstrapazierter Begriff zu sein und für alles zu stehen.. für manch einen.
Natürlich steht Schnittstelle erst mal für alles mögliche. In den 80ern unter TP hat man Schnittstellen programmiert um Drucker zu steuern, um beispielsweise auf DBase-Files zugreifen zu können etc. Das hatte aber alles nichts mit Interfaces im Sinne der OOP zu tun :/

Es gibt Unterschiede zwischen technischer und konzeptioneller Sicht.

COM, ActiveX, Dll sind übrigens ein Konzept eines Betriebssystems.. soweit ich weiß. Dennoch funktioniert die OOP auf jeder Plattform, weil sie einfach als Konzept was völlig anderes darstellt, als API-Calls oder so was zu verwursten.

[einbeliebigername]

Hallo,

Zitat von Sailor:

Gehen wir mal so 40 Jahre zurück. Da wurde neben dem Modulkonzept das Prinzip Information Hiding (heutzutage Encapsulation, Kapselung genannt) propagiert. Der Verwender einer Komponente (ich will hier nicht Objekt sagen, um keine Verwirrung zu stiften) sollte nur noch über Funktionen/Prozeduren auf deren Funktionalität zugreifen dürfen, ohne darüber informiert zu werden, wie diese Funktionalität realisiert worden ist. Warum das? Nun, neben den öffentlichen Eigenschaften kann eine Implementierung zusätzliche, nur ihr zukommende Eigenschaften haben. Der clevere Programmierer nutzt die natürlich. Da helfen keine Verbote. Und wenn jetzt aus irgendwelchen Gründen was geändert werden muß, dann ist diese implizite Eigenschaft möglicherweise weg, eventuell mit katastrophalen Folgen. Um das zu vermeiden, ist Kapselung eines der Grundprinzipien der OOP geworden.

Ja, dank der Sichtbarkeit kann man mit OOP Funktionalität vor anderen Verbergen.

Zitat von Sailor:

Leider ist in den gängigen OOP-Sprachen die konsequente Trennung von Interface und Realisierung aus mir unerfindlichen Gründen "vergessen" worden. In Delphi sind zwar zarte Versuche in dieser Richtung zu erkennen. Man hätte aber z. B. Interface und Implementation auf 2 Dateien aufteilen müssen.

Wieso müssen jetzt dafür unbedingt Klassen-Interface und Implementierung getrennt werden?

Zitat von Sailor:

Und in einem Interface dürfen nur die öffentlichen Funktionen/Prozeduren auftauchen. Alles andere wie Felder oder private Funktionen gehören in die Implementation.

Das ist allerdings ein Punkt den ich auch in Delphi vermisse. Wobei es auch so wie in C# um gesetzt sein kann. Also entweder man verzichtet auf interface-Teil und implementiation-Teil und arbeitet mit public und privat. Dann müsste man die Uses aber aufs gesamte Modul verteilen können. Oder aber man erlaubt, dass eine Klassendefinition im interface-Teil angefangen und im implementation-Teil fortgesetzt werden kann. Ich würde zu letzteres tendieren. Dann hätte man mittels include ein Art Partielle-Klassen-Konzept für Arme.

Zitat von Sailor:

Und von C# oder Java will ich gar nicht erstreden, die haben das ganz fallengelassen.

Woraus schließt du das? Zu Java kann ich nicht so viel sage, da zu lange her. Aber Java und auch C# kennen auch Sichtbarkeit.

Zitat von Sailor:

Und so weiß der Anwender immer noch, wie es gemacht wurde.

Wodurch erfährt der Anwender wie es gemacht wurde?

Zitat von Sailor:

Offensichtlich haben sich einige daran erinnert, daß das eigentlich verhindert werden sollte und das meines Wissens von COM herrührende Interface umgebogen, um dem Mangel abzuhelfen und stoßen nun kräftig ins Horn.

Ich glaube Interfaces wurden wegen etwas anderem eingeführt.

Zitat von Sailor:

Kann man machen, aber ob das zu besser lesbaren Programmen führt, wage ich zu bezweifeln. Auch die Themen Vererbung/Mehrfachvererbung, Parametrisierung von Klassen, Benutzung unterschiedlicher Implementierungen einunddesselben Interfaces in einem Programm sollten besser innerhalb einer OOP-Sprache gelöst werden.
Fazit: Ich verwende (COM-)Interfaces zur Realisierung von OOP-Interfaces nur dort, wo es angeraten erscheint, die Interna einer Implementierung vor dem Nutzer einer Klasse zu verbergen, mangels geeigneter Sprachkonstrukte. Aber vielleicht sehen wir in naher Zukunft ein Delphi 2.0, in dem das in aller Schönheit vorhanden ist.

Dem stimme ich zu.

[Ghostwalker]

Zitat von frapo:

Auch hier wird meines Wissens nach der Begriff Interface nicht im Sinne der OOP angewandt.

OOP hat mit Interfaces erstmal garnix zu tun (waren nie Bestandteil der OOP Definition).
Interfaces sind ein eigenständiges Konzept, das auf der OOP aufbaut

Ansonsten kann ich mich deinem Post nur anschließen frapo.

Zitat von Sailor:

Man hätte aber z. B. Interface und Implementation auf 2 Dateien aufteilen müssen.

Warum ? Das hätte nur zu Folge, das, analog C/C++, noch mehr Dateien rumfliegen. Mal abgesehen
davon, das das nix mit dem Interface-Konzept etwas zu tun hat.

[frapo]

Zitat von Ghostwalker:

Zitat von frapo:

Auch hier wird meines Wissens nach der Begriff Interface nicht im Sinne der OOP angewandt.

OOP hat mit Interfaces erstmal garnix zu tun (waren nie Bestandteil der OOP Definition).
Interfaces sind ein eigenständiges Konzept, das auf der OOP aufbaut

Hättest du dazu Quellen, gerne auch Literatur?

[stahli]

Ach manno...

Eigentlich ging es darum, dass Neulinge die Verwendung von Interfaces (unter Delphi) besser verstehen wollten.
Die aktuelle Diskussion dürfte eher wieder zur vollständigen Verwirrung beitragen.

Vielleicht wäre das in einem eigenständigen Interface-Philosophie-Thread besser aufgehoben...

[DeddyH]

@stahli:

[frapo]

Hm.. hast wohl leider recht stahli.

Vielleicht sollte ich die drei Links aus #48 und #54 einfach noch mal posten. Da steht ja eigentlich alles drin, was man wissen sollte, wenn man sich für das Thema interessiert.

http://openbook.rheinwerk-verlag.de/oop/
https://de.wikipedia.org/wiki/Schnit...schnittstellen
https://www.philipphauer.de/study/se...n/strategy.php.