Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

[Der schöne Günther]

Poetischer Titel. Und vielleicht passt es doch besser speziell nach Object-Pascal / Delphi-Language. Ich bin nicht sicher.

Mir ist heute etwas sehr interessantes aufgefallen: Nehmen wir folgenden Codeschnipsel:

Delphi-Quellcode:

   IMessageInterface = interface
   ['{F3B8FE2F-C64F-4E5B-B731-6ABB09CDF4E7}']
      procedure ShowMessage();
   end;

   TMessager = class(TInterfacedObject, IMessageInterface)
      private var
         myMessage: String;
      public
         constructor Create(const myMessage: String);
         procedure showMessage();
   end;

   TContainerClass = class(TInterfacedObject, IMessageInterface)
      private
         function getMessageDelegate(): TMessager;

      private var
         messageDelegate: TMessager;

      // Delegation: IMessageInterface
      property messageInterface: TMessager
      read getmessageDelegate implements IMessageInterface;

      public
         constructor Create();
         procedure createNewDelegateInstance();

    end;

Was passiert? Wir haben eine Klasse

Delphi-Quellcode:

TContainerClass

welche sich (in ihrem Konstruktor) eine

Delphi-Quellcode:

TMessager

-Instanz erstellt und die

Delphi-Quellcode:

ShowMessage

-Methode an diese abschiebt.
Die Methode

Delphi-Quellcode:

createNewDelegateInstance()

zerstört diese Instanz und erstellt eine neue. Unterscheiden kann man beide: Die erste gibt "Erste", die neue Instanz würde "Zweite" auf den Bildschirm ausgeben.

Soweit alles klar? Interessant finde ich nun, was man tatsächlich bekommt, wenn man sich von

Delphi-Quellcode:

TContainerClass

nun eine

Delphi-Quellcode:

IMessageInterface

-Referenz holt. Führen wir folgendes aus:

Delphi-Quellcode:

var
   container: TContainerClass;
   messageIntf: IMessageInterface;
begin
   container := TContainerClass.Create();
   Supports(container, IMessageInterface, messageIntf);
   messageIntf.ShowMessage();

sieht man erwartungsgemäß "Erster" auf dem Bildschirm. Schaut man im Debugger aber auf die Variable

Delphi-Quellcode:

messageIntf

sieht man dort:

Code:

Name   Wert
messageIntf   TMessager($286B964) as IMessageInterface

. Die Referenz hat überhaupt keinen Bezug mehr zu der

Delphi-Quellcode:

TContainerClass

-Instanz, wir haben hier direkt die

Delphi-Quellcode:

TMessager

-Instanz!

Warum ist das so? Hat das bestimmte Gründe?

Jetzt kommt der Punkt, der mich verwirrt: Ändern wir von

Delphi-Quellcode:

TConainerClass

die Methode

Delphi-Quellcode:

getMessageDelegate()

dass sie kein Interface (

Delphi-Quellcode:

IMessageInterface

) sondern eine Klasse (

Delphi-Quellcode:

TMessager

) zurückgibt, läuft die Sache ganz anders ab:
Nach dem Aufruf von

Delphi-Quellcode:

Supports(..)

haben wir in unserer Interface-Variable eine Referenz auf die

Delphi-Quellcode:

TContainerClass

-Instanz! Erst durch den folgenden Aufruf von

Delphi-Quellcode:

ShowMessage

wird die

Delphi-Quellcode:

getMessageDelegate

-Methode abgearbeitet, die TMessager-Instanz zurückgegeben und auf ihr schließlich

Delphi-Quellcode:

ShowMessage

aufgerufen.

Konkret bedeutet das:
Führen wir also folgendes (zwei Zeilen mehr) aus:

Delphi-Quellcode:

var
   container: TContainerClass;
   messageIntf: IMessageInterface;
begin
   container := TContainerClass.Create();
   Supports(container, IMessageInterface, messageIntf);
   messageIntf.ShowMessage();

   container.createNewDelegateInstance();
   messageIntf.ShowMessage();

Ergibt das im ersten Fall die Ausgabe

1. Erster
2. Erster

Während im zweiten Fall

1. Erster
2. Zweiter

ausgegeben wird.


Liest noch jemand mit? Meine Schlussfolgerung, was das konkret bedeutet: Nehmen wir an, äußere Umstände zwingen mein TContainerClass-Objekt nun dazu, dass es keine Message senden kann. Es bekommt von nirgendwo einen

Delphi-Quellcode:

TMessager

her. Alle sind ausverkauft. Als Ersatz liefert es nun ein Nullobjekt, einen Dummy.

Im ersten Fall lässt sich das nicht machen. Derjenige, der sich zum Zeitpunkt als ich nichts im Angebot hatte einmal eine Interface-Referenz geholt hatte bekommt nie mit, wenn ich denn einmal wieder ein vernünftiges

Delphi-Quellcode:

TMessager

-Objekt habe: Seine Referenz wird immer auf den Dummy zeigen.
Im zweiten Fall geht das - Nur muss sich mein Nullobjekt zwangsweise von TMessager ableiten. Das hat zahlreiche Probleme und Nachteile.

Folglich: Interface-Delegation an aggregierte Objekte. Und der Delegat ändert sich später. Das kann nicht gut gehen, oder? Oder verbeiße ich mich hier nur zu sehr in das "implements" Keyword? Würde ich für alle Interface-Methoden eine eigene Method Resolution Clause nehmen würde man alle Probleme umgehen. Aber hässlich das ist doch potthässlich. Ist das vom Konzept her insgesamt ein No-Go?

[Sir Rufo]

Häng doch mal ein SSCCE hier dran (oder sollen wir uns das aus deiner Beschreibung zusammenreimen?).

Ein kompletter Code (bzw. hier wohl eher 2 oder IFDEFs) sagt dann mehr als tausend Worte.

[Uwe Raabe]

Schau dir in der System.pas mal die Klassen TAggregatedObject und TContainedObject an. Die sind exakt für solche Konstrukte gedacht.

Das TAggregatedObject stellt ausdrücklich kein Interface zur Verfügung und gibt alle Aufrufe an QueryInterface und die Referenzzählung an den Controller zurück, während TContainedObject zwar auch die Referenzzählung über den Controller abwickelt, aber bei QueryInterface erstmal bei sich selbst nachsieht.

TAggregatedObject ist also der ideale Kandidat für implements. Es gibt auch Fälle für TContainedObject - es kommt eben darauf an, was man will.

[Der schöne Günther]

Vielen Dank für eure Zeit!

TAggregated/TContainedObject habe ich verstanden, denke ich. Die habe ich schließlich auch erst durch dich kennen gelernt :wink:

Aber die versprochene Lösung bringt es nicht: Die Aussage "Interface wird unterstützt ja/nein" wird zwar hier vom Parent abhängig gemacht, aber die resultierende Interface-Referenz zeigt auch hier wieder auf das aggregierte Objekt, nicht den Container.


Ein "Minimalbeispiel" kann man das mit 180 Zeilen schon nicht mehr nennen (als VCL-Formularanwendung). Mit IFDEFs wäre es mMn zu unübersichtlich. In den Anhang lege ich es noch als Projekt.

Vielleicht wäre eine Möglichkeit, eine gleichbleibene Delegaten-Instanz dazwischenzuhängen? Der muss dann halt wiederum das Interface implementieren und es letztendlich an das wirklich gewollte Objekt "dispatchen". Und der kann im Quelltext ja jetzt meinetwegen so hässlich sein wie er will. Die Gedanken werden langsam zu abstrus. Ich bin wohl schon zu lange wach.

Delphi-Quellcode:

unit Unit2;

interface

uses
   Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants,
   System.Classes, Vcl.Graphics,
   Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls;

type
   IMessageInterface = interface
   ['{F3B8FE2F-C64F-4E5B-B731-6ABB09CDF4E7}']
      procedure ShowMessage();
   end;

   TMessager = class(TAggregatedObject, IMessageInterface)
      private var
        myMessage: String;
      public
        constructor Create(
         const controller: IInterface;
         const myMessage: String
        );
        procedure showMessage();
   end;

   TOtherMessager = class(TAggregatedObject, IMessageInterface)
      procedure showMessage();
    end;

   // deligiert an ein Interface
   TContainerClass = class(TInterfacedObject, IMessageInterface)
      private
        function getMessageDelegate(): IMessageInterface;

      private var
        messageDelegate: IMessageInterface;

      // Delegation: IMessageInterface
      property messageInterface: IMessageInterface
      read getmessageDelegate implements IMessageInterface;

      public
        constructor Create();
        procedure createNewDelegateInstance();
   end;


   // deligiert an eine TMessager-Instanz. Und auf diese Klasse
   // bin ich jetzt festgenagelt
   TOtherContainerClass = class(TInterfacedObject, IMessageInterface)
      private
        function getMessageDelegate(): TMessager;

      private var
        messageDelegate: TMessager;

      // Delegation: IMessageInterface
      property messageInterface: TMessager
      read getmessageDelegate implements IMessageInterface;

      public
        constructor Create();
        procedure createNewDelegateInstance();
   end;



   TMyForm = class(TForm)
      delegateToInterfaceButton: TButton;
      delegateToClassButton: TButton;
      procedure FormCreate(Sender: TObject);
      procedure delegateToInterfaceButtonClick(Sender: TObject);
      procedure delegateToClassButtonClick(Sender: TObject);
   end;

var
   MyForm: TMyForm;

implementation

{$R *.dfm}

procedure TMyForm.delegateToInterfaceButtonClick(Sender: TObject);
var
   container: TContainerClass;
   messageIntf: IMessageInterface;
begin
   container := TContainerClass.Create();
   Supports(container, IMessageInterface, messageIntf);
   messageIntf.ShowMessage(); // Zeigt auf eine TMessager-Instanz

   container.createNewDelegateInstance(); // Jetzt wird an ein TOtherMessager delegiert
   messageIntf.ShowMessage(); // Zeit auf die alte TMessager-Instanz
end;


procedure TMyForm.delegateToClassButtonClick(Sender: TObject);
var
   container: TOtherContainerClass;
   messageIntf: IMessageInterface;
begin
   container := TOtherContainerClass.Create();
   Supports(container, IMessageInterface, messageIntf);
   messageIntf.ShowMessage(); // Zeigt auf eine TMessager-Instanz

   container.createNewDelegateInstance(); // Jetzt wird an ein TOtherMessager delegiert
   messageIntf.ShowMessage(); // Zeit auf eine mittlerweile tote TMessager-Instanz. Erzeugt AV
end;

procedure TMyForm.FormCreate(Sender: TObject);
begin

end;

{ TMessager }



constructor TMessager.Create(
   const controller: IInterface;
   const myMessage: String);
begin
   inherited Create(controller);
   self.myMessage := myMessage;
end;

procedure TMessager.showMessage();
begin
   Vcl.Dialogs.ShowMessage(myMessage);
end;

{ TContainerClass }

constructor TContainerClass.Create();
begin
   inherited Create();
   messageDelegate := TMessager.Create(self, 'Diese TMessager-Instanz wurde im Konstruktor erstellt');
end;

procedure TContainerClass.createNewDelegateInstance();
begin
   messageDelegate := TOtherMessager.Create(self);
end;

function TContainerClass.getMessageDelegate(): IMessageInterface;
begin
   Result := messageDelegate;
end;



{ TOtherMessager }

procedure TOtherMessager.showMessage;
begin
   Vcl.Dialogs.ShowMessage('Ich streike heute');
end;

{ TOtherContainerClass }

constructor TOtherContainerClass.Create();
begin
   inherited Create();
   messageDelegate := TMessager.Create(self, 'Diese TMessager-Instanz wurde im Konstruktor erstellt');
end;

procedure TOtherContainerClass.createNewDelegateInstance();
begin
   messageDelegate.Free();
   messageDelegate :=    TMessager.Create(self, 'Diese Instanz wurde irgendwann später erstellt');
   // Ich kann hier also nur von einer TMessager-Instanz auf eine andere
   // wechseln
end;

function TOtherContainerClass.getMessageDelegate(): TMessager;
begin
   Result := messageDelegate;
end;

end.

[Sir Rufo]

Aber was wundert dich denn jetzt? Das Verhalten ist doch logisch.

Du speicherst dir in einer Variablen eine Referenz auf ein Interface und du wunderst dich, wenn du dieser Variablen keinen neuen Wert zuweist, dass dann immer noch das Gleiche drin steht?

[Der schöne Günther]

Nein, was mich wundert ist die Tatsache dass ich entweder eine Referenz auf den Delegaten oder eine Referenz auf die "äußere" Klasse (TContainerClass) bekomme. Was ich nun bekommen werde kann ich nicht sehen. Denn das hängt davon ab, ob die "gefragte" Instanz (TContainerClass) nun intern an eine Klasse oder ein Interface delegiert.

Ich gehe der Idee mit einem "Zwischen-Delegat" mal weiter. Ich habe in so ziemlich jedem Bereich gewaltige Bildungslücken: Das Stellvertreter-Pattern kenne ich nur vom Namen her. Ich glaube, so etwas schwebt mir vor...

// Habe ich's?

• Die äußere Klasse (TContainerclass) delegiert an ein Interface. Somit liefert Supports eine Referenz auf den Delegaten und nicht TContainerClass
• TContainerClass weiß, dass sie ihren Delegaten möglicherweise ändern wird. Also delegiert sie nicht direkt an die gewünschte Instanz, sondern einen Proxy
• Ich habe keine Ahnung ob man das nun "Proxy" nennen darf oder ich hier Dinge durcheinander werfen
• Wenn die äußere Klasse nun den wirklichen Delegaten ändern will, injiziert sie auf ihrem Proxy einfach eine andere Instanz.
• Supports liefert weiterhin nur Referenzen auf den Proxy
• Der Proxy implementiert zwar alle Interface-Methoden nochmal manuell, aber das soll mir recht sein. Das ist schließlich auch genau seine Aufgabe und ich mülle mir mit so etwas nicht meine
  Delphi-Quellcode:

  TContainerClass

  zu.

Die äußere Klasse

Delphi-Quellcode:

   IProxy<T:IInterface> = interface
   ['{AF691ABC-D561-4E5D-BFF1-AC30D97F007A}']
      procedure setDelegate(const delegate: T);
      function getDelegate(): T;
   end;

   TSomeInterfaceProxy = class(TInterfacedObject, ISomeInterface, IProxy<ISomeInterface>)
      private var
         myDelegate: ISomeInterface;

      public
          constructor Create(const realDelegate: ISomeInterface); overload;

         // ISomeInterface
         procedure someProc();

         // IProxy<ISomeInterface>
            procedure setDelegate(const delegate: ISomeInterface);
            function getDelegate(): ISomeInterface;
   end;

[Sir Rufo]

Häh, bei beiden gezeigten Varianten wird das Interface an die interne Instanz weitergeleitet.
Also immer

Delphi-Quellcode:

TMessager

(nicht eher

Delphi-Quellcode:

TMessenger

?)

[Der schöne Günther]

Ja, "Messenger" nicht "Messager". Ich bin wohl schon zu lange wach. :drunken:

(Meinen letzten Beitrag habe ich in der Zwischenzeit aktualisiert)

Ja, weitergeleitet wird das Interface immer. Der Punkt ist dass ich in einem Fall direkt die Referenz auf den Delegaten bekomme. Das äußere Objekt könnte ich in der Zwischenzeit sogar freigeben. Das kann sogar gewollt sein.
Im anderen Fall zeigt meine Referenz NICHT auf den Delegaten - Er zeigt auf die äußere Klasse. Ändert die Klasse ihren Delegaten, spreche ich mit meiner Referenz immer den aktuellen Delegaten der Klasse an. Das finde ich toll! Das hat aber den Schwachpunkt, dass die Klasse ihren Delegaten intern als Klasse (und nicht als Interface) referenzieren muss.

Und nun glaube ich (mit dem Zwischen-Delegaten) eine Lösung zu haben.

[Sir Rufo]

Fast ... so sollte das gehen

Delphi-Quellcode:

  ISomeInterface = interface
    ['{A06F92AD-9E22-4EA9-9770-3B02C2AE8E5A}']
    procedure SomeProc( );
  end;

  IProxy<T : IInterface> = interface
    //['{AF691ABC-D561-4E5D-BFF1-AC30D97F007A}'] nicht bei Generics!
    procedure setDelegate( const delegate : T );
    function getDelegate( ) : T;
  end;

  TSomeInterfaceProxy = class( TInterfacedObject, ISomeInterface, IProxy<ISomeInterface> )
  private
    myDelegate : ISomeInterface;
  private
    constructor Create( const realDelegate : ISomeInterface );

    // ISomeInterface Delegate
    procedure DelegateSomeProc( );
    procedure ISomeInterface.SomeProc = DelegateSomeProc;

    // IProxy<ISomeInterface>
    procedure setDelegate( const delegate : ISomeInterface );
    function getDelegate( ) : ISomeInterface;
  public
    class function Construct( const realDelegate : ISomeInterface ) : ISomeInterface;
    class function ConstructProxy( const realDelegate : ISomeInterface ) : IProxy<ISomeInterface>;
  end;

{ TSomeInterfaceProxy }

class function TSomeInterfaceProxy.Construct( const realDelegate : ISomeInterface ) : ISomeInterface;
begin
  Result := TSomeInterfaceProxy.Create( realDelegate );
end;

class function TSomeInterfaceProxy.ConstructProxy( const realDelegate : ISomeInterface ) : IProxy<ISomeInterface>;
begin
  Result := TSomeInterfaceProxy.Create( realDelegate );
end;

constructor TSomeInterfaceProxy.Create( const realDelegate : ISomeInterface );
begin
  inherited Create;
  myDelegate := realDelegate;
end;

procedure TSomeInterfaceProxy.DelegateSomeProc;
begin
  getDelegate.SomeProc;
end;

function TSomeInterfaceProxy.getDelegate : ISomeInterface;
begin
  Result := myDelegate;
end;

procedure TSomeInterfaceProxy.setDelegate( const delegate : ISomeInterface );
begin
  myDelegate := delegate;
end;

und dann so benutzen

Delphi-Quellcode:

var
  LProxy : IProxy<ISomeInterface>;
  LSome : ISomeInterface;

LProxy := TSomeInterfaceProxy.Construct( TSome.Create );
Supports( LProxy, ISomeInterface, LSome );

LSome.SomeProc; // TSome.SomeProc
LProxy.setDelegate( TSomeOther.Create );
LSome.SomeProc; // TSomeOther.SomeProc

[Der schöne Günther]

Fantastisch! *händereib*

Spontan und nach kurzem Durchtesten würde ich sagen, das ist exakt, was ich wollte! :thumb: :cheers:

Ich würde weiterhin noch sagen, die Method Resolution Clause ist nicht nötig, gesetzt man hat keine Namenskonflikte und kann die Methode "DelegateSomeProc" im Proxy gleich "someProc" nennen.
Letztendlich könnte man sich jetzt noch Gedanken machen, was das sinnvollste wäre, wollte man eine leere Referenz injizieren.

Großartig, ich freue mich wirklich! Ich war anfangs ziemlich überrumpelt als ich gesehen habe, dass man unter Umständen direkt eine Referenz auf den Delegaten bekommt!