Thema: Delphi Umgang mit Interfaces

Einzelnen Beitrag anzeigen

TiGü

Registriert seit: 6. Apr 2011
Ort: Berlin
3.060 Beiträge
 
Delphi 10.4 Sydney
 
#36

AW: Umgang mit Interfaces

  Alt 13. Dez 2013, 13:32
Wer meint es besser zu wissen bzw. sein Anwendungsfall es unbedingt erfordert, muss ja nicht von TInterfacedObject ableiten,
Die RefCount Methoden kann man zwar überschreiben, aber die Grundproblematik von Delphi wird man dadurch nicht los.
Ehrlich gesagt kann ich dir jetzt nicht mehr so ganz folgen was denn die "Grundproblematik" sein soll.
Kannst du hierauf nochmal eingehen?
Das es COM-Interfaces sind - also einen gewissen sprachübergreifenden Standard folgen - ist jetzt aber nicht das "Problem", oder?

Delphi ruft z.B weiterhin lustig die Refenz-Count Methoden von Objekten auf, auch wenn das Objekt z.B. schon freigegeben wurde.
Die zur Zeit einzig sinnvolle Lösung für das Problem nennt sich Free-Pascal...
Dann lass es doch weiterhin lustig aufrufen.
Solange du in den selbstimplementierten _AddRef und _Release Methoden kein Schindluder betreibst geht das doch?!?
Wo ist das Problem?
Oder verhält sich das in Free-Pascal anderes?

Delphi-Quellcode:
  ISomeThing = Interface(IInterface)
  ['{16CCA417-F4C4-4B4A-88CE-FDD79B875876}']
    function DoSomeThing : Integer;
  End;

  TMyInterfacedObject = class(TObject, IInterface)
  protected
    function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
    function _AddRef: Integer; stdcall;
    function _Release: Integer; stdcall;
  end;

  TMyDoSomething = Class(TMyInterfacedObject, ISomeThing)
  protected
    function DoSomeThing : Integer;
  end;

...

function TMyInterfacedObject.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
  if GetInterface(IID, Obj) then
    Result := 0
  else
    Result := E_NOINTERFACE;
end;

function TMyInterfacedObject._AddRef: Integer;
begin
  Result := -1;
end;

function TMyInterfacedObject._Release: Integer;
begin
  Result := -1;
end;

...

var
  MySomeThingObject : ISomeThing;
begin
  MySomeThingObject := TMyDoSomething.Create;
  MySomeThingObject.DoSomeThing;
  (MySomeThingObject as TMyDoSomething).Free;

  // folgendes funktioniert problemlos, obwohl das Objekt freigeben wurde!
  MySomeThingObject._AddRef;
  MySomeThingObject._AddRef;
  MySomeThingObject._AddRef;
  MySomeThingObject._Release;
end;


Die "automatische" Referenzverwaltung von Inferface-Objekten ist in meinen Augen sehr bequem und ermöglicht ein sehr komfortables modernes programmieren.
Ich denke, dass jemand, der "automatische" Referenzverwaltung für bequem hält, vom Thema insgesamt herzlich wenig verstanden hat.
Das ist fast genauso beknackt wie die Forderung der ActiveX Retro-Gurus, dass man Objekte und Interfaces nicht mischen sollte.

Leute. Nehmt einfach einen vernünftigen Compiler und reitet nicht für immer rum auf diesen Lehrsätzen für COM-Interfaces, die Microsoft mal in der Antike verkündet hat.
Ja nun, ich denke mir mal meinen Teil dazu.
Es gab immer Leute die meinen es besser zu wissen.

COM ist aktueller denn je, weiß nicht was das mit Antike zu tun haben sollte.
Mein Rechner läuft auf Windows 8.1 und da ist das "Kachelstartmenü" durchgehend mit dieser Technologie umgesetzt.

Zeige uns doch bitte mal einen typischen Anwendungsfall in deiner Applikation, wo der Einsatz von COM-Interfaces zu Fehlern führt und stattdessen das von dir gewünschte Verhalten besser wäre.

In meiner Applikation sind ein Großteil der Klassen über Interfaces ansprechbar und das nicht mischen von Objekt- und Interfacereferenzen gewöhnt man sich auch schnell an.
Weiß nicht worin da die Schwierigkeit besteht das konsequent durchzuziehen.
Gleichermaßen könnte man sich darüber aufregen, dass der Compiler nicht folgendes zur Compilezeit anmeckert:

Delphi-Quellcode:
 
var
  a, b, c : Integer;
begin
  a := 0;
  c := b div a;
end;
  Mit Zitat antworten Zitat