gemischter Interface-/Objektzugriff

[Lemmy]

Servus,

beim Einsatz von Interfaces muss man ja tunlichst darauf achten, Interfaces und Objektzugriff nicht zu mischen, da es sonst zur automatischen Freigabe kommen kann, da die Objektvariable nicht zum RefCount zählt.

Nehmen wir folgendes Beispiel

Delphi-Quellcode:

  IFooItem = Interface
   ['{9995E78E-45DF-4C25-B657-7396738FEA70}']
   procedure Bar;
  end;

  TFooItem = class(TinterfacedObject, IFooItem)
  public
    procedure Bar;
    procedure Foo(const AValue);
  end;

Der Konsument meines Interfaces muss lediglich auf die Methode Bar zugreifen. Allerdings benötige ich beim Erzeugen / Initialisieren / Aktualisieren in meinem Owner der Objektinstanz auch die Methode Foo.

Delphi-Quellcode:

  TFooOwner = class
  private
    Fitem: TFooItem
    function GetItem: IFooItem
  public
    property Item: IFooItem getItem;
    procedure ChangeItem(const AValue);
  end;#


....
 procedure TFooOwner.ChangeItem(const AValue)
 begin
   FItem.Foo(AValue);
 end;

Greife ich mit dem Code oben einmal auf Item zu wird aus dem FItem das Interface geholt, übergeben und wenn die aufrufende Methode beendet ist, wird das Interface genilt, der Refcounter kommt bei 0 an und FItem wird frei gegeben.

Die einzige Lösung für das Problem die ich kenne wäre, die Referenzzählung zu "deaktivieren". Die Freigabe der Instanz ist ja kein Problem, da ein Eigentümer da ist, der sich darum kümmert.

Allerdings wird im Netz (und auch hier) davon abgeraten die Referenzzählung zu umgehen - nur warum? Oder Alternativ: Welche andere Möglichkeit gibt es für eine solche Implementierung?

[Uwe Raabe]

Grundsätzlich gilt: Solange du weißt, was du tust, ist alles erlaubt.

Für deinen Fall würde ich statt von

Delphi-Quellcode:

TInterfacedObject

von

Delphi-Quellcode:

TInterfacedPersistent

ableiten, das genau dafür gemacht ist.

[himitsu]

Erstmal mußt du entscheiden was führend ist und der Großteil der Referenzen sollte dann in Modus sein.

1: Interface mit Referenzzählung und wenn nötig, dann wird daraus "kurzzeitig" eine Objektreferenz geholt (z.B. TInterfacedObject)
2: Objekt ohne Referenzzählung ist führend und man kann daraus kurzzeitig Interfacereferenzen holen (z.B. TInterfacedPersistent)

Ein Beispiel für 2 ist die VCL, da kannst du jedes TComponent nach einem Interface fragen und so gleiche Funktionalität in unterschiedliche Klassen (auch nachträglich) einbauen.

PS: Etwas neuere Delphis können auch

Delphi-Quellcode:

MyIntf as TMyObject

, da dort ein virtuelles Interface in TObject steckt, was "intern" per Supports statt einer Interfacereferenz die Objektreferenz raus holt, ohne das man selber ein GetMyObject (Result := Self) bauen muß.

PPS: Unter ARC hat Delphi Interfaces und Objekte vermanscht.
Beides ist "immer" referenzgezählt (außer bei

Delphi-Quellcode:

var [Weak] Variable: xxx;

) und nutzt eine gemeinsame Zählung.

[Lemmy]

Zitat:

Zitat von Uwe Raabe (Beitrag 1371839)

Grundsätzlich gilt: Solange du weißt, was du tust, ist alles erlaubt.

LOL
ich weiß, dass ich nichts weiß.... :-)

Danke für Eure Tipps, über TInterfacedPersistent bin ich auch schon gestolpert, war mir aber etwas unsicher bzgl. des FOwnerInterface. Schaut aber ganz gut aus im ersten Test...

Zitat:

Zitat von himitsu (Beitrag 1371842)

PS: Etwas neuere Delphis können auch

Delphi-Quellcode:

MyIntf as TMyObject

, da dort ein virtuelles Interface in TObject steckt, was "intern" per Supports statt einer Interfacereferenz die Objektreferenz raus holt, ohne das man selber ein GetMyObject (Result := Self) bauen muß.

ja, das habe ich auch gelesen. Bin aber noch ein paar Wochen im Delphi 7 Modus. Allerdings finde ich das aktuell noch ziemlich böse :-)

[himitsu]

Eigentlich ist es ja böse, wenn man aus einem "abstrakten" Inteface ein Objekt macht, da ja die Implementation hinter dem Interface eigentlich "geheim" ist.

Aber aus Sicht des Delphi und wenn man hinter dem Interface ein Objekt hat, ist es so vollständiger.
* Objekt zu Interace geht ja schon ewig und ganz einfach (auch ohne Supports)
* und nun auch andersrum

Geht seit Galileo-IDE Version 7, also ab Delphi 2010.
Blöd für dich ... Delphi 7 ist Delphi-IDE Version 7, aber das war auch die letzte Version des AppBuilder (genannt Delphi)

Delphi-Quellcode:

var
  I: IInterfaceComponentReference;
  O: TComponent;
begin
  I := TComponent.Create(Self);
  O := TComponent.Create(Self);
  I := O as IInterfaceComponentReference;  // nötig, wenn I z.B. nur IInterface wäre
  I := O;  // hier wird das Interface der Variable genommen
  O := I as TComponent;  // und bei Objekten ist alles die selbe Referenz, egal auf welche Klasse es gecastet wurde, aber bei I>O ist der Cast nur "explizit" möglich
end;

Vor Delphi 2010 brauchte man z.B. sowas

Delphi-Quellcode:

IInterfaceComponentReference = interface
  ['{E28B1858-EC86-4559-8FCD-6B4F824151ED}']
  function GetComponent: TComponent;
end;

function TComponent.IntfGetComponent: TComponent;  // function IInterfaceComponentReference.GetComponent = IntfGetComponent;
begin
  Result := Self;
end;

[freimatz]

Zitat:

Zitat von Lemmy (Beitrag 1371828)

Der Konsument meines Interfaces muss lediglich auf die Methode Bar zugreifen. Allerdings benötige ich beim Erzeugen / Initialisieren / Aktualisieren in meinem Owner der Objektinstanz auch die Methode Foo.

Ei warum denn? Ich vermute das Problem eher hier.
Dass Du die Methode Foo brauchst - ok. Aber dann auf die Objektinstanz zuzugreifen halte ich für falsch. Du könntest
a) Foo auch auf das Interface geben.
b) ein zweiters Interface machen
Ich tendiere dazu Implementierungen von interfaces komplett zu verstecken und nur noch eine Fabrikmethode nach außen zu geben.

[Lemmy]

Zitat:

Zitat von freimatz (Beitrag 1371909)

a) Foo auch auf das Interface geben.
b) ein zweiters Interface machen

a) will ich nicht, weil der Konsument da nix zu schreiben hat. und b) Zeig doch bitte Code

Delphi-Quellcode:

  IFooItem = Interface
   ['{9995E78E-45DF-4C25-B657-7396738FEA70}']
   procedure Bar;
  end;

  IFooFooItem =Interface
   ['{9995E78E-45DF-4C25-B657-7396738FEA70}']
    procedure Foo(const AValue);
  end;

  TFooItem = class(TinterfacedObject, IFooItem, IFooFooItem)
  public
    procedure Bar;
    procedure Foo(const AValue);
  end;

und jetzt der Owner:

Delphi-Quellcode:

 TFooOwner = class
  private
    Fitem: XXXXX
    function GetItem: IFooItem
  public
    property Item: IFooItem getItem;
    property FooItem: IFooFooItem GetFooItem;
  end;

Wie wird jetzt die Instanz von FItem gespeichert? Als einzigste Lösung würde mir wieder die ObjektInstanz einfallen und in den Get* Methoden dann ein GetInterface(IFooXItem, Result)aber dann habe ich wieder einen Zugriff auf die Objektinstanz!?!?

[stahli]

Es gibt kurz gesagt, eigentlich drei wesentliche Gründe für den Einsatz von Interfaces unter Delphi:

- gleiche Funktionalität in unterschiedlichen Klassen (ohne gemeinsame Basisklasse) als Alternative zur nicht vorhandenen Mehrfachvererbung
- Benutzung von Referenzzählung und automatischer Freigabe (wenn man das will)
- evtl. Einbindung von DLLs

Man erreicht eine abstrakte Beschreibung von Datenfeldern und Funktionen, ohne die genaue Implementation in den Klassen kennen zu müssen.

In Deinem Bespiel erkenne ich nicht, warum Du in einem Fall plötzlich mit Interfaces arbeiten willst/musst.

Werden ganz unterschiedliche Klassen an Deine Funktion übergeben?

Den geringsten Umstellungsaufwand hast Du sicher mit dem Vorschlag von Uwe.
Dann kannst Du einfach normal mit Deinen Objekten arbeiten und dieses einfach einmalig in Form eines Interfaces an die Funktion übergeben.

Eine andere Möglichkeit wäre die Umstellung insgesamt auf Interfaces, das würde aber einiges an Mehraufwand und grundsätzlichen Änderungen mit sich bringen.

Interfaces sind nützlich, aber man sollte abwägen, ob sie im vorliegenden Fall Vorteile bringen...

[Fritzew]

Zitat:

- gleiche Funktionalität in unterschiedlichen Klassen (ohne gemeinsame Basisklasse) als Alternative zur nicht vorhandenen Mehrfachvererbung
- Benutzung von Referenzzählung und automatischer Freigabe (wenn man das will)
- evtl. Einbindung von DLLs

Für mich der wichtigste Punkt:
- Decoupling des Codes, also keine Abhängigkeiten im Source ala Class1 kennt Class2 kennt Class3 die wieder Class1 kennt, etc..
Dadurch wird der Code auch besser Testbar. Wenn man dann noch hingeht und die Interfaces in die Klassen hineingibt, bekommt man schlanken wartbaren Code.

[himitsu]

Das kannst du aber auch mit abstakten Klassen erreichen.

Das extern Bekannte wird abstrakt definiert und deine Klasse1-3 leiten dann halt jeweils von sowas ab.
siehe TStrings oder TStream