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.
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.
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.
...
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.