Schnittstelle ohne COM-Eigenschaft

[Mikkey]

Es mag vielleicht banal klingen, aber in bin zuletzt aus der C#-Ecke gekommen und möchte gern die dort gewonnenen Design-Goodies auch als Delphi-Neuling weiterverwenden.

Wenn ich ein Interface deklariere, und in einer Klasse unsetze, verlangt der Compiler von mir, dass ich die IUnknown-Methoden implementiere. Ich habe aber gar nicht vor, COM-Objekte zu erstellen, sondern möchte eine Schnittstelle in verschiedenen Klassen verwenden, um sie auf einheitliche Weise ansprechen zu können.

Ebenso kann ich dabei die Release-Logik absolut nicht gebrauchen, lässt sich die abschalten?

Gibt es eine solche Möglichkeit in Delphi nicht?

[Der schöne Günther]

Ich dachte, jedes Interface leitet sich erst einmal von

Delphi-Quellcode:

IInterface

ab? Solange du kein COM willst, sollte

Delphi-Quellcode:

IUnknown

da doch erst gar nicht ins Spiel kommen?

Das konkrete Objekt muss (eher: sollte), sobald es auch nur ein Interface implementiert, sich von

Delphi-Quellcode:

TInterfacedObject

als Elternklasse ableiten. Oder halt einer Klasse, die

Delphi-Quellcode:

TInterfacedObject

schon irgendwo als Vorfahr hat. Denn das implementiert die Standard-Interface-Methoden wie

Delphi-Quellcode:

_Release

bereits.

Oder habe ich was falsch verstanden?

[sx2008]

Leider geht das nicht so einfach und reibungslos wie bei C# :(
Interfaces unter Delphi müssen immer von

Delphi-Quellcode:

IUnknown

oder

Delphi-Quellcode:

IInterface

(was das Gleiche ist) abgeleitet werden.
Damit du die Methoden von

Delphi-Quellcode:

IUnknown

nicht selbst implementieren musst, kannst du von der Klasse TInterfacedObject ableiten.

Wenn man einen Interfacezeiger hat ist es auch nur mit Klimmzügen möglich wieder an das eigentliche Klassenobjekt zu kommen.
Das bedeutet man kann ein Objekt, dass über ein Interface referenziert wird nicht einfach mit

Delphi-Quellcode:

Free

freigeben weil man über das Interface gar nicht an die Free-Methode herankommt.
Daraus folgt, dass man immer die Referenzzählung von IUnknown benutzen sollte (auch wenn man die Referenzzählung aushebeln kann und sie dabei aber weitere Schwierigkeiten einhandelt)

[Mikkey]

Zitat:

Zitat von Der schöne Günther (Beitrag 1226268)

Ich dachte, jedes Interface leitet sich erst einmal von

Delphi-Quellcode:

IInterface

ab? Solange du kein COM willst, sollte

Delphi-Quellcode:

IUnknown

da doch erst gar nicht ins Spiel kommen?

Ich habe IUnknown ja nicht verlangt, sondern der Compiler (das ist das Interface, das QueryInterface etc. enthält). Bei Delphi ist IUnknown halt mit IInterface bezeichnet.

Zitat:

Zitat von Der schöne Günther (Beitrag 1226268)

Das konkrete Objekt muss (eher: sollte), sobald es auch nur ein Interface implementiert, sich von

Delphi-Quellcode:

TInterfacedObject

als Elternklasse ableiten. Oder halt einer Klasse, die

Delphi-Quellcode:

TInterfacedObject

schon irgendwo als Vorfahr hat. Denn das implementiert die Standard-Interface-Methoden wie

Delphi-Quellcode:

_Release

bereits.

Ich möchte bei den Klassen vielleicht eine andere Basisklasse haben bzw. habe keinen Einfluss auf deren Basisklasse, weil die Klassen bereits vorhanden sind.

Außerdem möchte ich gern vermeiden, dass der COM-Unterbau darunter ist. Bei C# geht das auch, warum muss Delphi unbedingt COM ins Spiel bringen.

[Mikkey]

Zitat:

Zitat von sx2008 (Beitrag 1226271)

Wenn man einen Interfacezeiger hat ist es auch nur mit Klimmzügen möglich wieder an das eigentliche Klassenobjekt zu kommen.
Das bedeutet man kann ein Objekt, dass über ein Interface referenziert wird nicht einfach mit

Delphi-Quellcode:

Free

freigeben weil man über das Interface gar nicht an die Free-Methode herankommt.
Daraus folgt, dass man immer die Referenzzählung von IUnknown benutzen sollte (auch wenn man die Referenzzählung aushebeln kann und sie dabei aber weitere Schwierigkeiten einhandelt)

Das bedeutet, die Delphi-Interfaces sind im Wortsinn gar keine Interfaces sondern COM-Objektbeschreibungen (wie bei C/C++)?

welche Möglichkeiten gibt es denn, die Interfaces wie Interfaces zu verwenden? Ich möchte gern Objekte verschiedener Klassen, die bestimmte Eigenschaften gemeinsam haben auch gemeinsam verwenden. C++ hat dafür die Mehrfachvererbung, C# die frei verwendbaren Interfaces. Das COM dabe die Objekte einfach wegschmeißt, darf dabei natürlich nicht passieren.

[sx2008]

Zitat:

Zitat von Mikkey (Beitrag 1226272)

Außerdem möchte ich gern vermeiden, dass der COM-Unterbau darunter ist. Bei C# geht das auch, warum muss Delphi unbedingt COM ins Spiel bringen.

Tja, das geht halt nicht.
Der frühere Chefentwickler von Turbo Pascal & Delphi Anders Hejlsberg ist zu Microsoft gewechselt und dort die C# Entwicklung massgeblich voran getrieben.
C# ist im Prinzip ähnlich zu Delphi nur dass die Schwächen von Delphi in C# behoben wurden.
Interfaces wurden in Delphi erst nachträglich eingebaut.
Man merkt das unter anderem daran, dass die VCL Klassenbibliothek so gut wie keinen Gebrauch von Interfaces macht.
Interfaces sind in Delphi mehr oder weniger ein Fremdkörper geblieben.

Zitat:

Zitat von Mikkey (Beitrag 1226272)

Das bedeutet, die Delphi-Interfaces sind im Wortsinn gar keine Interfaces sondern COM-Objektbeschreibungen (wie bei C/C++)?

Das könnte man so sagen.
In Delphi sind Interfaces eine Einbahnstrasse.
Man kann einen Objektzeiger in einen Interfacezeiger umwandeln (

Delphi-Quellcode:

iz := meinobjekt as IMeinInterface

) aber die umgekehrte Richtung ist nicht vorgesehen.

[Mikkey]

Zitat:

Zitat von sx2008 (Beitrag 1226275)

Zitat:

Zitat von Mikkey (Beitrag 1226272)

Außerdem möchte ich gern vermeiden, dass der COM-Unterbau darunter ist. Bei C# geht das auch, warum muss Delphi unbedingt COM ins Spiel bringen.

Tja, das geht halt nicht.

schade

Zitat:

Zitat von sx2008 (Beitrag 1226275)

Man merkt das unter anderem daran, dass die VCL Klassenbibliothek so gut wie keinen Gebrauch von Interfaces macht.

Naja, Windows-Forms benutzen AFAIR auch keine Interfaces.

Zitat:

Zitat von sx2008 (Beitrag 1226275)

In Delphi sind Interfaces eine Einbahnstrasse.
Man kann einen Objektzeiger in einen Interfacezeiger umwandeln (

Delphi-Quellcode:

iz := meinobjekt as IMeinInterface

) aber die umgekehrte Richtung ist nicht vorgesehen.

Das würde mich ja nicht stören, in C# kann man aus einer Interfacereferenz auch nur mittels Cast wieder zum Objekt kommen - ist ja auch nicht Sinn der Sache, auch wenn's wegen der RTTI sicher funktioniert:

iz = meinobjekt;

meinobjekt = iz as meineklasse;

Es geht mir nur darum, dass ich mir nicht eine Interfacereferenz hole und die mir dadurch, wenn ich sie nicht mehr brauche, das Objekt weghaut.

[mkinzler]

Zitat:

Man merkt das unter anderem daran, dass die VCL Klassenbibliothek so gut wie keinen Gebrauch von Interfaces macht.

FMX dafür um so mehr

[Mikkey]

Um mal in die Richtung Konstruktivität zu kommen...

Kann ich dort, wo ich meine Klassen erzeuge (und wo sie später irgendwann entfernt werden sollen) den Referenzzähler um eins erhöhen und dort, wo das Objekt definitiv nicht mehr gebraucht wird, diesen Referenzzähler herunterzählen?

So wäre sichergestellt, dass das Objekt nicht ausversehen ins Nirwana verschwindet.

Oder kann ich in meinen Klassen den Referenzzähler komplett ignorieren und den Free auf das Objekt weiterverwenden? Wäre mir ehrlich gesagt am liebsten.

[r2c2]

Zitat:

Zitat von Mikkey (Beitrag 1226286)

Kann ich dort, wo ich meine Klassen erzeuge (und wo sie später irgendwann entfernt werden sollen) den Referenzzähler um eins erhöhen und dort, wo das Objekt definitiv nicht mehr gebraucht wird, diesen Referenzzähler herunterzählen?

Ja. Dafür sind die Methoden verantwortlich, die du von IUnknown erbst und in TInterfacedObject für dich implementiert sind.

Zitat:

Oder kann ich in meinen Klassen den Referenzzähler komplett ignorieren und den Free auf das Objekt weiterverwenden? Wäre mir ehrlich gesagt am liebsten.

Es gibt auch einen Hack über den du die Referenzzählung ausschalten kannst. Dazu musst du AFAIR den Referenzzähler im Konstruktor erhöhen. Somit wird der nie 0 und es verschwindet nix.

Du kannst die Referenzzählung aber auch nutzen. Das programmiert sich dann so ähnlich wie die Smartpointer aus C++. Hab ich noch nicht gemacht, aber es gibt manche, die das wirklich mögen. Näheres zu Interfaces liest du z.B. bei Nick Hodges.


mfg

Christian

[Furtbichler]

Warum sollte man denn die Referenzzählung manipulieren wollen? Vergiss 'Free' einfach komplett. Verwende deine Objekte/Interfaces wie gewohnt, aber rufe niemals Free auf. Das brauchst Du nicht!

Wenn Du Objekte in einer Liste hältst und weißt genau, das Du das Element nicht mehr benötigt, dann entferne es aus der Liste.
Wenn Du ein globales Objekt freigeben willst, fang von vorne an :mrgreen: (keine globalen Objekte) oder weise der Instanzvariablen einfach nil zu.

[Mikkey]

Zitat:

Zitat von r2c2 (Beitrag 1226307)

Ja. Dafür sind die Methoden verantwortlich, die du von IUnknown erbst und in TInterfacedObject für dich implementiert sind.

TInterfacedObject kann ich nicht verwenden, weil ich bei den Klassen, für die es gedacht ist, nicht einfach eine neue Basisklasse unterziehen kann.

Zitat:

Zitat von r2c2 (Beitrag 1226307)

Es gibt auch einen Hack über den du die Referenzzählung ausschalten kannst. Dazu musst du AFAIR den Referenzzähler im Konstruktor erhöhen. Somit wird der nie 0 und es verschwindet nix.

Im Code von TInterfacedObject steht nichts weiter als "

Delphi-Quellcode:

dec(refCount); if refCount = 0 then Destroy;

". Da würde ich einen solchen Weg nicht wirklich als Hack sehen. Nach einem "CoCreateInstance" wird der Zähler schließlich auch mit 1 initialisiert und eine Klassenreferenz ist im weiteren Sinn auch eine Schnittstellenreferenz.

Zitat:

Zitat von r2c2 (Beitrag 1226307)

Du kannst die Referenzzählung aber auch nutzen. Das programmiert sich dann so ähnlich wie die Smartpointer aus C++. Hab ich noch nicht gemacht, aber es gibt manche, die das wirklich mögen. Näheres zu Interfaces liest du z.B. bei Nick Hodges.

Es gibt Dinge, die mache ich nur, wenn etwas Anderes nicht praktikabel erscheint. In C/C++ und Delphi erzeugt man Klassenobjekte selbst. Es gibt keinen wirklichen Grund, sich da einer müllsammlerähnlichen Technik anzuvertrauen. COM hat seine eigenen Regeln, da kommt man nicht drumherum. In C# hat man ebenso keine andere Chance.

[Mikkey]

Zitat:

Zitat von Furtbichler (Beitrag 1226345)

Warum sollte man denn die Referenzzählung manipulieren wollen? Vergiss 'Free' einfach komplett. Verwende deine Objekte/Interfaces wie gewohnt, aber rufe niemals Free auf. Das brauchst Du nicht!

Es geht nicht um eine Neuprogrammierung. Es handelt sich um Klassen, die bereits existieren und die in einer bestehenden Anwendung angelegt und zerstört werden. Daran werde ich sicher nichts ändern.

Es geht nur darum, dass die bestehenden Objekte nach verschiedenen Aspekten "ähnlich" sind und bzgl. dieser Ähnlichkeit von einzelnen Methoden verwendet werden.

Beispiele (es geht nicht nur um visuelle Objekte):

Einstellungen von Formularelementen lassen sich per XML-Knoten konfigurieren oder können ihre Eigenschaften in einem XML-Knoten zurückliefern.

Formularelemente können Ausgang/Ziel einer Drag-and-Drop-Aktion sein.

Solche Dinge lassen sich viel besser handhaben, wenn man ein Objekt fragen kann, ob IIrgendwas unterstützt wird und dann IIrgendwas für die weitere Arbeit benutzt.

Die Referenzzählung ist dann zu nichts nütze und nichts weiter als lästig

[uligerhardt]

Zitat:

Zitat von Mikkey (Beitrag 1226352)

Die Referenzzählung ist dann zu nichts nütze und nichts weiter als lästig

Ich benutze da folgende Basisklasse:

Delphi-Quellcode:

type
  TPureInterfacedObject = class(TObject, IInterface)
  protected
    { IInterface }
    function QueryInterface(const IID: TGUID; out Obj): HResult; virtual; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  end;

{ TPureInterfacedObject }

function TPureInterfacedObject.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
  Result := E_NOINTERFACE;
end;

function TPureInterfacedObject._AddRef: Integer;
begin
  Result := -1;
end;

function TPureInterfacedObject._Release: Integer;
begin
  Result := -1;
end;

Damit generiert der Compiler zwar immer noch Aufrufe für _AddRef und _Release, aber die töten das betroffene Objekt nicht.

[Mikkey]

Zitat:

Zitat von uligerhardt (Beitrag 1226357)

Damit generiert der Compiler ...

Jetzt ist das Brett weg, vielen Dank.

Wenn die Sachen vom Compiler übernommen werden, ist es zwar immer noch überflüssig, aber nicht mehr lästig, es stört dann nicht mehr so sehr.

Bei Klassen, unter denen ohnehin TInterfacedObject liegt, muss es bisher auch funktioniert haben, bei den anderen habe ich dadurch, dass ich _Release selbst implementieren muss, ohnehin die Kontrolle.