Umgang mit Interfaces

[TiGü]

Zitat von Whookie:

Da man aber Supports nicht ohne eine IID_xxx aufzurufen kann, muss man hier wieder ein konkretes Interface angeben. Also etwa:

Delphi-Quellcode:

function TMyList.Get<T>(const AIndex: Integer): T;
begin
  if not Supports(FList[AIndex].fMy, IID_BASE, Result) then
    Result := nil;    
end;

Das ist so nicht richtig, siehe Doku:

Delphi-Quellcode:

function Supports(const Instance: IInterface; const IID: TGUID; out Intf): Boolean;
function Supports(const Instance: TObject; const IID: TGUID; out Intf): Boolean;
function Supports(const Instance: IInterface; const IID: TGUID): Boolean;
function Supports(const Instance: TObject; const IID: TGUID): Boolean;
function Supports(const AClass: TClass; const IID: TGUID): Boolean;

Wobei IID hier auch direkt ein Interface-Typ sein kann (IMyFunnyInterface, IInteger, IDoSomeThing).

Codebeispiel anhand deines Falls:

Delphi-Quellcode:

type
  TMyDoSomething = Class(TMyCompare, IInteger, ISomeThing)
  ...
  end;

var
  MySomeThingObject : ISomeThing;
begin
  MySomeThingObject := TMyDoSomething.Create;
  if Supports(MySomeThingObject, IInteger) then
  begin
    ShowMessage('IInteger wird voll unterstützt!!!');
  end;
end;

[Whookie]

Zitat von TiGü:

Delphi-Quellcode:

  ...
var
  MySomeThingObject : ISomeThing;
begin
  MySomeThingObject := TMyDoSomething.Create;
  if Supports(MySomeThingObject, IInteger) then
  begin
    ShowMessage('IInteger wird voll unterstützt!!!');
  end;
end;

... und laut Doku ist das Objekt damit auch zerstört und damit kann man diese Variante nicht verwenden...

Edit: Habe nicht erwähnt das ich meine Klassen nicht als Interface speichern kann (ISomeThing muss zu TSomeThing werden), weil ich eben eine "Basisliste" mit allen Klassen habe. Diese stehen untereinander in verschiedenen Beziehungen und pflegen daher eigene TNodeList-en um eine Referenz auf diese benötigten Instanzen zu haben. Durch diese Verlinkung schnellt der _RefCount bei verwendung von Interfaces aber hoch und am Programmende, wenn die "Basisliste"-alles frei gibt, bleibt ein riesiges Memoryleek über.

[jaenicke]

Zitat von Whookie:

Edit: Habe nicht erwähnt das ich meine Klassen nicht als Interface speichern kann (ISomeThing muss zu TSomeThing werden), weil ich eben eine "Basisliste" mit allen Klassen habe.

Das ist dann keine gute Architektur, lässt sich aber bei Einführung von Interfaces in alte Quelltexte manchmal nicht vermeiden. In neuen Quelltexten ist das allerdings ein No-Go.

Dann solltest du die Referenzzählung auf jeden Fall in allen Objekten deaktivieren. Es macht keinerlei Sinn die zu nutzen, wenn du nicht durchgängig mit Interfaces arbeitest.

Das haben wir als Notlösung bei der Umstellung in alten Quelltexten vorübergehend auch gemacht, sind aber mittlerweile so weit, dass wir es größtenteils richtig, sprich nur mit Interfaces, umgesetzt haben. Das ist bei Verwendung von Interfaces ja die einzige sinnvolle Variante.

[JamesTKirk]

Zitat von Whookie:

Habe nicht erwähnt das ich meine Klassen nicht als Interface speichern kann (ISomeThing muss zu TSomeThing werden), weil ich eben eine "Basisliste" mit allen Klassen habe.

Du könntest mal probieren, ob's richtig funktioniert, wenn du bei deinen Klassen explizit _AddRef aufrufst, bevor du es in deine Liste speicherst. Damit sagst du der Referenzzählung ja, dass da noch eine Referenz ist. Bevor du die Klasse dann freigibst musst du diese Referenz dann wieder mit _Release lösen und wenn keine andere Referenz auf eines der Interfaces der Klasse vorhanden ist, sollte sie auch gleich automatisch freigegeben werden.

Gruß,
Sven

[Stevie]

Ändere einfach in deinem Ausgangspost fMy von TMyClasses auf IInterface und benutz dann die Version mit Supports (GUIDs auf den Interfaces nicht vergessen) - dann zerbröselt es dir deine Referenzzählung nicht.

[Sir Rufo]

Oder sogar doppelt ... falls die Basis-Instanz als Klasse benötigt wird

Delphi-Quellcode:

TListData = class
private
  fAsIntf : IInterface;
  fAsObj: TMyClasses;
  fName: String;
  fHash: Cardinal;
public
  property AsIntf : IInterface read fAsIntf;
  property AsObj : TMyClasses;
  property Name : string read fName;
  property Hash : Cardinal read fHash;
End;

Und beim Destroy von TListData einfach mal nicht die Objekt-Instanz befreien

[TiGü]

Zitat von Whookie:

Zitat von TiGü:

Delphi-Quellcode:

var
  MySomeThingObject : ISomeThing;
begin
  MySomeThingObject := TMyDoSomething.Create;
  if Supports(MySomeThingObject, IInteger) then
  begin
    ShowMessage('IInteger wird voll unterstützt!!!');
  end;
end;

... und laut Doku ist das Objekt damit auch zerstört und damit kann man diese Variante nicht verwenden...

Lesen und verstehen der Doku sind zwei Paar Schuhe!
Was unter der Überschrift "Warnung" als kryptischer 53 Wörter Satz steht, heißt nicht weiter als:
"Pass ja auf wenn du Interface- mit Objektreferenzen mischt, dass kann nämlich ganz schön in die Hose gehen wenn du mit Supports arbeitest."
Auch hier gilt: Nicht die Supports-Funktion ist schlecht oder fehlerhaft, sondern der Programmierer hat einen Fehler gemacht!

Um beim Beispiel zu bleiben, das hier funktioniert so wie es soll:

Delphi-Quellcode:

var
  MySomeThingObject : ISomeThing; // <--- das ist so richtig
begin
  MySomeThingObject := TMyDoSomething.Create;
  if Supports(MySomeThingObject, IInteger) then
  begin
    ShowMessage('IInteger wird voll unterstützt!!!');
  end;
  MySomeThingObject.DoSomeThing;
end;

Während das hier schief geht, wenn in DoSomeThing auf objekteigene Werte zugegriffen wird, denn die sind dann schon freigeben und genullt:

Delphi-Quellcode:

var
  MySomeThingObject : TMyDoSomething; // <--- da ist die entscheidene Stelle, Fehler!!!
begin
  MySomeThingObject := TMyDoSomething.Create;
  if Supports(MySomeThingObject, IInteger) then
  begin
    ShowMessage('IInteger wird voll unterstützt!!!');
  end;
  MySomeThingObject.DoSomeThing;
end;

[Patito]

Zitat von TiGü:

Auch hier gilt: Nicht die Supports-Funktion ist schlecht oder fehlerhaft, sondern der Programmierer hat einen Fehler gemacht!

Delphi-Quellcode:

var
  MySomeThingObject : ISomeThing; // <--- das ist so richtig

Während das hier schief geht, wenn in DoSomeThing auf objekteigene Werte zugegriffen wird, denn die sind dann schon freigeben und genullt:

Delphi-Quellcode:

var
  MySomeThingObject : TMyDoSomething; // <--- da ist die entscheidene Stelle, Fehler!!!

Naja. Der Fehler liegt doch etwas tiefer. Letztenendes ist es der Fehler der Compiler-Entwickler, die die Interfaces bei Delphi vermasselt haben. Diese Idee vom 'Interfaces nie als Objekte verwenden' stammt doch aus der Zeit, als man noch geglaubt hat, dass alle Objekt in 5 Monaten nur noch ActiveX-Objekt sein werden, (und dass das mehr oder weniger der heilige Gral ist). Im Licht der täglichen Praxis und im Angesicht von Design-Patterns erscheint diese Idee ziemlich absurd.

Eine solidere Lösung wäre einen Compiler zu verwenden, der besser ist (z.B. FreePascal mit "Corba-Interfaces").
Wenn man bei Delphi bleibt muss man eben den unsichtbaren Refenz-Zähler Kram so gut es geht aushebeln und höllisch aufpassen.

P.S: Zur Laufzeit mit Supports zu arbeiten ist etwas, was man so gut es geht vermeiden sollte. Eine Haupterrungenschaft der Objektorientierung war, dass man statt mit schwammigen Pointern jetzt mit feste Typen arbeiten kann. Wenn man jetzt wieder anfängt zur Laufzeit Pointer herumcasten ist das irgendwie sehr Retro.

[jaenicke]

Zitat von Patito:

Eine solidere Lösung wäre einen Compiler zu verwenden, der besser ist (z.B. FreePascal mit "Corba-Interfaces").
Wenn man bei Delphi bleibt muss man eben den unsichtbaren Refenz-Zähler Kram so gut es geht aushebeln und höllisch aufpassen.

Richtig nutzen wäre eine Alternative... sprich nur Interfaces verwenden oder keine.

Zitat von Patito:

P.S: Zur Laufzeit mit Supports zu arbeiten ist etwas, was man so gut es geht vermeiden sollte. Eine Haupterrungenschaft der Objektorientierung war, dass man statt mit schwammigen Pointern jetzt mit feste Typen arbeiten kann. Wenn man jetzt wieder anfängt zur Laufzeit Pointer herumcasten ist das irgendwie sehr Retro.

Eben das passiert ja nicht. Supports prüft ja, ob das Interface unterstützt wird, arbeitet also ähnlich wie as bei Objekten. Deshalb ist das ja gerade typsicher. Im Gegensatz zu einem harten Cast bei Objekten.

[TiGü]

Zitat von Patito:

Eine solidere Lösung wäre einen Compiler zu verwenden, der besser ist (z.B. FreePascal mit "Corba-Interfaces").
Wenn man bei Delphi bleibt muss man eben den unsichtbaren Refenz-Zähler Kram so gut es geht aushebeln und höllisch aufpassen.

Wer meint es besser zu wissen bzw. sein Anwendungsfall es unbedingt erfordert, muss ja nicht von TInterfacedObject ableiten, sondern kann selber die IInterface-Methoden implementieren bzw. wie schon von Günther angesprochen mit System.Generics.Defaults.TSingletonImplementation arbeiten.

Die "automatische" Referenzverwaltung von Inferface-Objekten ist in meinen Augen sehr bequem und ermöglicht ein sehr komfortables modernes programmieren.
Ähnliches wurde ja im Next-Gen-Compiler für mobile Platformen von Emba umgesetzt.

Zitat von Patito:

P.S: Zur Laufzeit mit Supports zu arbeiten ist etwas, was man so gut es geht vermeiden sollte. Eine Haupterrungenschaft der Objektorientierung war, dass man statt mit schwammigen Pointern jetzt mit feste Typen arbeiten kann. Wenn man jetzt wieder anfängt zur Laufzeit Pointer herumcasten ist das irgendwie sehr Retro.

Das ist so auch nicht richtig und zu dogmatisch.
Oft liegt der Fall vor, dass ein Objekt zwei bis drei Interfaces implementiert.
Je nachdem muss man dann zwangsläufig testen, ob ein bestimmtes Interface unterstützt wird.

Siehe auch die obigen Beispiele.
Hast du nur ein Objekt von Typ IInteger vorliegen, musst aber schauen ob ISomeThing unterstützt wird (oder umgekehrt) -> wie sollte man es sonst machen?