Polymorphie und Interfaces in Delphi

[alda]

Ja da ist Delphi etwas eigen, aber der Grund für dieses Verhalten würde mich auch interessieren.

Alle Interfaces die eine Klasse unterstützen soll (für das Casten zur Laufzeit), müssen explizit von dieser Klasse implementiert werden, bei voneinander abgeleiteten Interfaces auch die Super-Interfaces wie Du gemerkt hast. Ausnahme wäre, dass eine Superklasse diese bereits implementiert, dann musst Du die Interfaces in deiner abgeleiteten Klasse nicht noch einmal explizit mit in die Klassendeklaration nehmen.

@himitsu:
Aber eine Klasse die IExtendedInterface implementiert, implementiert doch auch implizit IBaseInterface. In welcher Hinsicht macht das "Sinn", dass man nicht nach IBaseInterface casten kann, ohne dieses Interface zusätzlich noch mit in die Deklaration aufzunehmen.

[himitsu]

Den Grund hab ich in meinem letzten Post nacheditiert.

[alda]

Ok, also ist dieses Verhalten der TGUID Verwendung "geschuldet". Dennoch hätte ich erwartet, dass Embacadero es schafft einfach die GUIDs aller Super-Interfaces mit einzutragen ... andererseits ... :>

[himitsu]

Das wäre aber auch nicht so gut, wenn Delphi das einfach so machen würde, denn es kann ja gewollt sein, daß IBaseInterface nicht supported wird und was macht man dann?

Das mit den GUIDs liegt an Windows und nicht an Delphi.
Nur die GUID ist wichtig und den Namen interessiert keinen.
Du kannst das Interface problemlos umbenennen, bzw. jedes Programm/DLL kann einen anderen Namen vor dem Compilieren verwenden, solange die GUID und die ordinalen Positionen der beliebig benennbaren Methoden gleich bleibt.

[alda]

Zitat:

Das wäre aber auch nicht so gut, wenn Delphi das einfach so machen würde, denn es kann ja gewollt sein, daß IBaseInterface nicht supported wird und was macht man dann?

Genau darauf will ich ja hinaus: Gibt es diesen Fall? Ich hätte gesagt nein, da ich über das IExtendedInterface auch das IBaseInterface implementiere.

[Uwe Raabe]

Zitat von alda:

Zitat:

Das wäre aber auch nicht so gut, wenn Delphi das einfach so machen würde, denn es kann ja gewollt sein, daß IBaseInterface nicht supported wird und was macht man dann?

Genau darauf will ich ja hinaus: Gibt es diesen Fall? Ich hätte gesagt nein, da ich über das IExtendedInterface auch das IBaseInterface implementiere.

Diesen Fall wird es spätestens in dem Moment geben, wo Delphi das nicht mehr unterstützen würde. Die Tatsache, daß wir uns vielleicht im Moment keinen derartigen Fall vorstellen können, ist allenfall ein Zeichen unseres beschränkten Denkens und kein Beweis, daß es ihn nicht gibt oder geben wird.

[Mikkey]

Zitat von Uwe Raabe:

Zitat von alda:

Zitat:

Das wäre aber auch nicht so gut, wenn Delphi das einfach so machen würde, denn es kann ja gewollt sein, daß IBaseInterface nicht supported wird und was macht man dann?

Genau darauf will ich ja hinaus: Gibt es diesen Fall? Ich hätte gesagt nein, da ich über das IExtendedInterface auch das IBaseInterface implementiere.

Diesen Fall wird es spätestens in dem Moment geben, wo Delphi das nicht mehr unterstützen würde. Die Tatsache, daß wir uns vielleicht im Moment keinen derartigen Fall vorstellen können, ist allenfall ein Zeichen unseres beschränkten Denkens und kein Beweis, daß es ihn nicht gibt oder geben wird.

Tut mir leid, wenn ich da widerspreche, aber wenn ein Objekt das Interface IExtendedInterface anbietet muss es per Definition auch IBaseInterface anbieten.

Wenn ich eine Klasse definiere, die IExtendedInterface implementiert, bekomme ich schließlich auch einen Compilerfehler, wenn sie nicht die Methoden von IBaseInterface implementiert.

Wenn ich den obigen Code leicht modifiziere, wird er vom Compiler anstandslos geschluckt:

Delphi-Quellcode:

var obj: TKlasse;
begin
  // ...
  Irgendwas(IExtendedInterface(obj));
end;

Es fehlt also schlicht und einfach der implizite Cast von Objektreferenz auf das implementierte Interface.

[himitsu]

Zitat von alda:

Genau darauf will ich ja hinaus: Gibt es diesen Fall? Ich hätte gesagt nein, da ich über das IExtendedInterface auch das IBaseInterface implementiere.

Vererben ist bei Interfaces halt ein bissl anders.
Von außen kann man nicht auf die Methoden des Vorfahren zugreifen.
Man kommt da nur daran, wenn man die Interfaceinstanz auf den Vorfahren castet (als Typcast und nicht über Supports), wenn man weiß, daß dort etwas drin ist.

Ich hatte das mal verwendet, um in der Codevervollständigung die Liste kürzer zu halten, da man in Interfaces keine private-Abschnitt deklarieren kann, worin sich Getter und Setter verstecken lassen.

[alda]

Zitat:

Man kommt da nur daran, wenn man die Interfaceinstanz auf den Vorfahren castet (als Typcast und nicht über Supports), wenn man weiß, daß dort etwas drin ist.

Das ist ein Spezialfall. Der Vorfahre alleine repräsentiert nur zwei alleinstehende, öffentliche Methoden (Setter und Getter, ohne zugehörige Property). Sobald Du über den Nachfahren gehst, erkennt Delphi, dass die Getter und Setter zu der Property gehören. In meinem Beispiel hättest Du auf dem Nachfahren auch den Zugriff auf die Methoden des Vorfahren (also wie auch bei normalen Methoden, ohne Properties)