Interfaces + Factorys

[Sailor]

Die wesentliche Grundidee der Objektorientierung ist Information Hiding,
auch Datenkapselung genannt. Der Nutzer soll nur gewisse Gebrauchswerte
kennen, die er ausschließlich verwendet. Er weiß über den internen Ablauf nichts.
Beispiel Tabelle: Die Nutzerfunktionen seien Eintragen eines Elementes und Abfragen,
ob ein Item Element der Tabelle ist. Je nach Anwendungsfall kann das nun unterschiedlich
implementiert werden, als lineare Liste, als Hashtabelle, als Datenbank etc.
Zumindest in dieser Hinsicht ist Delphi keine objektorientierte Sprache,
so wie auch C# und insbesondere Java das nicht sind.
In dem hier verwendeten Kontext sind Interfaces nun die Krücke, mit der versucht wird,
das nachträglich in Delphi hinzubekommen. Das geht aber nur auf der syntaktischen
Ebene, denn es gibt in diesen Sprachen keinerlei Mittel, mit denen man die Semantik
auf der abstrakten oder Nutzerebene ausdrücken kann. Die Benennung einer Prozedur
als "Flieg" hindert doch niemanden daran, die als "Schwimm" zu implementieren. Um auf
das oben angedeutete Beispiel zurückzukommen: Was passiert, wenn ein Element
mehrfach eingetragen wird? Ist es dann nur einmal drin? Wie reagiert die Funktion Abfragen,
wenn das Element nicht in der Tabelle vorhanden ist? Ohne Einsicht in die Implementierung
lassen sich diese Informationen nicht gewinnen. Man kann durch die Verwendung von Interfaces
oder abstrakter Klassen sicher einiges entkoppeln, aber letztendlich bleibt der Einblick in das
Innere einer Klasse unverzichtbar, wenn man in Delphi & Konsorten programmiert, leider.

[stahli]

Ja, das stimmt absolut.
Und genau darauf wollte ich hier hinaus: WIE genau "Flieg" oder "GetData" in den Klassen genau realisiert werden kann, sollte hier nicht unbedingt besprochen werden.
DASS das natürlich aber in den Klassen gelöst werden muss (und nicht in der Schnittstelle) ist natürlich richtig.

[mjustin]

Zitat von Sailor:

... ist Delphi keine objektorientierte Sprache,
so wie auch C# und insbesondere Java das nicht sind.

Dem ist wohl nichts hinzuzufügen. In diesem Kontext steht die Programmierung
in Delphi, Java und C# dem direkten Schreiben von Maschinencode näher als
echte Hochsprachen wie zum Beispiel Assembler, oder dem seit jeher bewährten
copy con > programm.exe.

[Dejan Vu]

Zitat von Sailor:

...
Zumindest in dieser Hinsicht ist Delphi keine objektorientierte Sprache,
so wie auch C# und insbesondere Java das nicht sind.
...Ohne Einsicht in die Implementierung
lassen sich diese Informationen nicht gewinnen. Man kann durch die Verwendung von Interfaces
oder abstrakter Klassen sicher einiges entkoppeln, aber letztendlich bleibt der Einblick in das
Innere einer Klasse unverzichtbar, wenn man in Delphi & Konsorten programmiert, leider.

Welche Programmiersprachen sind dann objektorientiert? Bei welcher Programmiersprache erkenne ich die komplette Spezifikation, ohne die Spezifikation zu lesen?

In einem normalen Kaufvertrag steht doch auch nicht, ob ich eins auffe Fresse kriege oder eine kolumbianische Krawatte bekomme, wenn ich nicht zahle. Es geht bei einem Vertrag doch gerade nicht um das Verhalten der Klassen/Objekte, sondern um die Interaktion. Oder willst Du das Verhalten eines Vertrages gleich mit deklarieren? Das wäre natürlich ein interessanter Ansatz. Wo gibt es das? Oder meinst Du aspektorientierte Programmierung sei ein Schritt in diese Richtung?