gemischter Interface-/Objektzugriff

[Fritzew]

Zitat:

Zitat von himitsu (Beitrag 1371933)

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

Klar, aber in meinen Augen ist eine Abstrakte Klasse eigentlich auch nichts anderes als ein Interface. Halt ohne Referenzzählung. Und ich muss von der Basisklasse ableiten. Aber das ist eine Wahl die jeder für sich und seinen Code entscheiden muss.

[Lemmy]

Zitat:

Zitat von stahli (Beitrag 1371924)

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

weil ich einen Part aus dem aktuellen Delphi 7 Projekt in einem neueren Delphi implementieren muss, weil es mit Delphi 7 einfach Probleme macht / nicht funktioniert. Und da die Gesamtumstellung noch auf sich warten lässt wandert der Part in die DLL.

Und die DLL (als Konsument) soll dabei nur die notwendigsten Informationen/Möglichkeiten bekommen, in meiner Anwendung aber brauch ich gerade zum Zeitpunkt der Initialisierung die eine oder andere Funktion mehr.

Beispiel: Eine Liste von Objekten (bzw. Interfaces) die in der DLL abgearbeitet werden müssen. Die DLL braucht weder neue Elemente der Liste hinzufügen noch löschen, daher definiert das dafür zuständige Listen-Interface auch nur eine get und eine count Methode.

[mjustin]

Spannende Frage. Ich würde es intuitiv so machen:

Delphi-Quellcode:

  private
    FItem: IFooItem;
    FFooItem: IFooFooItem;

und dann im Kontruktor:

Delphi-Quellcode:

constructor TFooOwner.Create(const AItem: TFooItem);
begin
  inherited Create;

  FItem := AItem; 

  FFooItem := AItem; 
end;

Das mit der Referenzzählung ist immer spaßig, man kann dann aber auch über Logging der aktuellen Referenzanzahl einiges schneller aufdecken als im Debugger.

[freimatz]

Bischen viel Quote, Sorry

Zitat:

Zitat von Lemmy (Beitrag 1371914)

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

ok ich ergänze gleich mal deinen

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; 
  
  function CreateItem():IFooItem;
  
...
  
  function CreateItem():IFooItem;
  begin
    Item := TFooItem.Create() as IFooItem;
  end;

und jetzt der Owner:

Delphi-Quellcode:

 TFooOwner = class
  private
    Fitem: IFooItem
    function GetItem: IFooItem
  public
    property Item: IFooItem getItem;
    property FooItem: IFooFooItem GetFooItem;
  end;
...
procedure TFooOwner.DoAbc();
var FooFooItem: IFooFooItem;
begin
  if not Supports(Item, IFooFooItem) then raise EPanic...;
  FooFooItem := Item as IFooFooItem;
  FooFooItem.Foo(abc)
end;

Zitat:

Zitat von Lemmy (Beitrag 1371914)

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!?!?

Gespeichert als interface. Immer und überall. Vermischen ist böse.
Die beiden interfaces würde ich dann auch nicht in eine unit packen.

[Stevie]

Ich sehe da einen gewissen "friend" Status bei deinen beiden Klassen. In solchen Fällen lasse ich da auch schonmal fünfe gerade sein und nutze intern die Klasse, auf welche extern nur über das Interface zugegriffen wird als Objekt.

Handelt es sich dabei um TInterfacedObject Nachfahren, nutz ich _AddRef und _Release an den Stellen wo ich mein internes Objekt feld setze bzw wenn der Owner freigegeben wird.

Das hat denselben Effekt wie als Interface zu speichern aber ich kann noch auf die Methoden, die nicht im Interface vorhanden sind zugreifen (plus wenn relevant bessere Performance und sogar inlining möglich, aber das sei nur am Rande erwähnt)

Ob du das machst oder von einer Klasse erbst, die keine Referenzzählung und entsprechende Speicherverwaltung implementiert, hängt letztlich davon ab, was per Design länger lebt, wenn das irgendwelche Referenzen auf das Interface sein können, dann nutz ich die erste Möglichkeit um keine Interface referenzen auf schon freigegebene Instanzen zu befürchten, ist es anders herum, kann man die zweite Möglichkeit erwägen.

[Blup]

Wenn beim Erzeugen des Objektes zusätzliche Methoden oder Properties angesprochen werden, braucht man dafür eigentlich kein zweites Interface.
Man muss nur klar abgrenzen, bis wo ohne Referenzzählung mit dem Objekt gearbeitet wird. Danach sollte das Objekt nicht mehr direkt referenziert werden.

Delphi-Quellcode:

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

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

  TFooOwner = class
  private
    FItem: IFooItem
    function CreateItem: TFooItem;
    function GetItem: IFooItem;
  public
    property Item: IFooItem GetItem;
  end;

implementation

function TFooOwner.CreateItem: TFooItem;
begin
  Result := TFooItem.Create;
  Result.Bar;
end;

function TFooOwner.GetItem: IFooItem;
begin
  if not Assigned(FItem) then
    FItem := CreateItem; // Referenzzählung beginnt
 
  Result := FItem;
end;