 matze hat folgendes geschrieben: |
ah ok. Das ist ja cool. Aber ich kann eine Klasse von mehreren Interfaces etwas erben lassen oder?
BTW: Kennt denn jemand ein Tutorial, wie man nun mit Interfaces umgeht? Denn: Aus meiner Informatik-Vorlesung weiß ich zwar, wie man in Java mit Interfaces arbeitet, aber nicht, wie man das in Delphi macht... |
Die Interface-Funktionalität in Delphi wird vor allem für COM Anwendungen verwendet, kann aber für jeden anderen Zweck auch gebraucht werden. Man sieht Interfaces in gewöhnlichen VCL Anwendungen relativ selten, obwohl meiner Meinung nach völlig unbegründet. Die VCL selbst verwendet Interfaces nicht an sehr vielen Orten. Ein Beispiel wäre TForm.Designer. Dort hängt sich der Design-Editor der IDE rein, um Mausklicks abzufangen, um die Komponenten verschiebbar zu machen (Dank Verwendung von Interfaces könntest du dort deine eigene Designer-Implementierung reinhängen).
Der Gebrauch von Interfaces verändert aber u.U. die Handhabung von Objekten etwas. Auch leidet die Geschwindigkeit bei Verwendung von Interfaces etwas darunter. Wenn eine Klasse ein Interface implementiert, fügt der Compiler automatisch Code für die automatische Referenzzählung der Objekte ein. So wird bspw. bei Verwendung von lokalen Interface-Variablen speziellen Code beim Austritt der Funktion generiert (analog zu Strings); und bei jeder Zuweisung an eine Interface-Variable werden zusätzlich zur Zuweisung Support-Funktionen aufgerufen, die die Referenzzählung updaten. Dies ist wie gesagt für COM-Anwendungen wichtig, damit die Objekte an "einem anderen Ort" auch automatisch wieder freigegeben werden, wenn diese nicht mehr verwendet werden. Oft verzichtet man jedoch innerhalb eines Delphi-Projekts auf die Referenzzählung (so ist dies z.B. bei TComponent der Fall, da diese Klasse über eine eigene Speicherfreigabe über einen Owner Mechanismus verfügt). Jedoch muss immer ein Handling für Referenzzählung gegeben sein, auch wenn die nur die Anweisung zurückgibt, dass keine Referenzzählung erwünscht ist. Wie du siehst kann dies enormen Overhead für nichts bedeuten.
Auf der anderen Seite machen die Interfaces die Verwendung verschiedener Design-Patterns und Architekturüberlegungen erst möglich. Dass eine Klasse mehrere Interfaces implementieren kann ist dabei natürlich zentral. In Delphi kannst du sogar eine Interface Implementation in einer separaten Klasse halten und diese in mehreren Klassen verwenden.
Last but not least: Nur dank voller Integration von (COM) Interfaces in die Sprache ist es möglich, ActiveX Komponenten mal so eben schnell in ein Delphi-Programm reinzuladen (z.B. Windows Media Player, eingebettetes Word-Fenster, Flash Plugin, oder auch Scripting Engines ...). Was in C++ nur mit "Smart Pointern" und viel Gemüse drumherum möglich ist, ist das ganze in Delphi in die Sprache integriert. So kannst du z.B. in weniger als 10 Zeilen Code einen JScript Interpreter in dein Delphi-Programm laden und z.B. über Delegation beliebige Delphi-Objekte dem JScript-Interpreter bekannt machen, sodass diese über JS-Skripts ansteuerbar werden.
