Umgang mit Interfaces

[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:

Zitat von Whookie (Beitrag 1239470)

Zitat:

Zitat von TiGü (Beitrag 1239253)

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:

Zitat von TiGü (Beitrag 1239483)

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:

Zitat von Patito (Beitrag 1239490)

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:

Zitat von Patito (Beitrag 1239490)

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:

Zitat von Patito (Beitrag 1239490)

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:

Zitat von Patito (Beitrag 1239490)

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?

[OlafSt]

Eine Frage zum Verständnis für jemanden, der mit Interfaces noch nie zu tun hatte:

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;

Sehe ich das richtig, das mein

Delphi-Quellcode:

MySomeThingObject

bei Verlassen der Prozedur automatisch freigegeben wird, obwohl ich zuvor mit

Delphi-Quellcode:

TMyDoSomething.Create;

Speicher dafür alloziert habe ?

[mezen]

Wenn in TMyDoSomething Referenzzählung enthalten ist (z.B. weil von TInterfacedObjekt abgelitten), dann ja, wird es bei Erreichen von 0 Referenzen automatisch freigegeben.

[Der schöne Günther]

Und da die einzige Referenz darauf eine lokale Variable war, ist der Referenzzähler beim Verlassen der Methode Null.

Nicht nur beim normalen Verlassen, natürlich auch, wenn deine Methode mittendrin per Exception rausfliegt. Damit spart man sich das ganze nervige

Delphi-Quellcode:

try..finally..Destroy

-Geraffel.

[jaenicke]

Zitat:

Zitat von Der schöne Günther (Beitrag 1239552)

Nicht nur beim normalen Verlassen, natürlich auch, wenn deine Methode mittendrin per Exception rausfliegt. Damit spart man sich das ganze nervige

Delphi-Quellcode:

try..finally..Destroy

-Geraffel.

Aber nur im Quelltext, bei Interfaces wird das nur mit noch mehr automatisch generiertem Code beim Kompilieren hinzugefügt.