gemischter Interface-/Objektzugriff

[freimatz]

Zitat von Lemmy:

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

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

[Fritzew]

Zitat von 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

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

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.

[freimatz]

Bischen viel Quote, Sorry

Zitat von Lemmy:

Zitat von freimatz:

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

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.