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 IInterface ab? Solange du kein COM willst, sollte IUnknown da doch erst gar nicht ins Spiel kommen?

Das konkrete Objekt muss (eher: sollte), sobald es auch nur ein Interface implementiert, sich von TInterfacedObject als Elternklasse ableiten. Oder halt einer Klasse, die TInterfacedObject schon irgendwo als Vorfahr hat. Denn das implementiert die Standard-Interface-Methoden wie _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 IUnknown oder IInterface (was das Gleiche ist) abgeleitet werden.
Damit du die Methoden von 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 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 von Der schöne Günther:

Ich dachte, jedes Interface leitet sich erst einmal von IInterface ab? Solange du kein COM willst, sollte 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 von Der schöne Günther:

Das konkrete Objekt muss (eher: sollte), sobald es auch nur ein Interface implementiert, sich von TInterfacedObject als Elternklasse ableiten. Oder halt einer Klasse, die TInterfacedObject schon irgendwo als Vorfahr hat. Denn das implementiert die Standard-Interface-Methoden wie _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 von sx2008:

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 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 von Mikkey:

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 von Mikkey:

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 ( iz := meinobjekt as IMeinInterface ) aber die umgekehrte Richtung ist nicht vorgesehen.

[Mikkey]

Zitat von sx2008:

Zitat von Mikkey:

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 von sx2008:

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 von sx2008:

In Delphi sind Interfaces eine Einbahnstrasse.
Man kann einen Objektzeiger in einen Interfacezeiger umwandeln ( 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 von Mikkey:

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