Delphi-PRAXiS - Schon wieder: Warum Interfaces

Hallo,

Zitat:

Zitat von Sailor (Beitrag 1351670)

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:

Zitat von Sailor (Beitrag 1351670)

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:

Zitat von Sailor (Beitrag 1351670)

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:

Zitat von Sailor (Beitrag 1351670)

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:

Zitat von Sailor (Beitrag 1351670)

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

Wodurch erfährt der Anwender wie es gemacht wurde?

Zitat:

Zitat von Sailor (Beitrag 1351670)

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:

Zitat von Sailor (Beitrag 1351670)

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.