AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Delphi Den Delegaten nachträglich ändern - Unterschiedliches Verhalten
Thema durchsuchen
Ansicht
Themen-Optionen

Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

Ein Thema von Der schöne Günther · begonnen am 29. Jan 2014 · letzter Beitrag vom 30. Jan 2014
Antwort Antwort
Der schöne Günther

Registriert seit: 6. Mär 2013
6.212 Beiträge
 
Delphi 10 Seattle Enterprise
 
#1

AW: Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

  Alt 29. Jan 2014, 22:10
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 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;

Geändert von Der schöne Günther (29. Jan 2014 um 22:39 Uhr) Grund: Geistige Meisterleistung am späten Abend
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#2

AW: Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

  Alt 29. Jan 2014, 22:35
Häh, bei beiden gezeigten Varianten wird das Interface an die interne Instanz weitergeleitet.
Also immer TMessager (nicht eher TMessenger ?)
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.212 Beiträge
 
Delphi 10 Seattle Enterprise
 
#3

AW: Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

  Alt 29. Jan 2014, 22:45
Ja, "Messenger" nicht "Messager". Ich bin wohl schon zu lange wach.

(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.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#4

AW: Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

  Alt 29. Jan 2014, 22:48
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
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)

Geändert von Sir Rufo (29. Jan 2014 um 23:00 Uhr)
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.212 Beiträge
 
Delphi 10 Seattle Enterprise
 
#5

AW: Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

  Alt 29. Jan 2014, 22:54
Fantastisch! *händereib*

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

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!
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.758 Beiträge
 
Delphi 12 Athens
 
#6

AW: Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

  Alt 29. Jan 2014, 23:22
Bei Verwendung von implements muss das implementierende Objekt entweder das besagte Interface bereitstellen (mittels QueryInterface) oder das Interface implementieren (sprich: die Methoden bereitstellen). Im ersten Fall bekommt man einen Interface-Zeiger auf den Implementer, im anderen auf den Container.

Wenn der Implementer von TAggregatedObject abgeleitet wird ohne das ein Interfacename in der Deklaration auftaucht, dann auch wird kein Interface-Zeiger zurückgegeben. Andernfalls würde das schon geschehen, aber durch die Implementierung von QueryInterface gelangt man für weitere Interfaces doch wieder zum Controller/Container.

Beim ersten Ansatz (TAggregatedObject ohne Interface-Deklaration) reicht es auch, wenn nur Teile des Interfaces von der Implementor-Klasse bereitgestellt werden, solange die fehlenden Methoden vom Container implementiert werden.

Delphi-Quellcode:
type
  IMyInterface = interface
    [<GUID>]
    procedure Foo;
    procedure Bar;
  end;

  TMyImplementor = class(TAggregatedObject)
    procedure Foo;
  end;

  TMyContainer = class(TInterfacedObject, IMyInterface)
  ...
  protected
    procedure Bar;
    property MyImplementor: TMyImplementor read GetMyImplementor implements IMyInterface;
  end;
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.052 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#7

AW: Den Delegaten nachträglich ändern - Unterschiedliches Verhalten

  Alt 30. Jan 2014, 07:27
Tja, man lernt jeden Tag was neues. Das Verhalten beim Delegieren an ein Objekt war mir neu, aber sehr interessantes und u.U. nützliches Verhalten.

@Günther
In deinem Beispiel im Eingangspost hast du übrigens ein Speicherleck (bzw verfrühte Freigabe einer Instanz).

Der Supports Aufruf auf container führt dazu, dass danach deine container Instanz freigegeben wird. Auch hier sollte container schon ein Interface sein, damit da nix schief geht.

Keine Ahnung, was der XE5 Debugger anzeigt, aber bei mir (XE) zeigt er im Fall, dass die Eigenschaft TMessage zurückgibt nur Pointer(...) as IMessageInterface an. Ein (messageIntf as TObject).ClassName liefert mir dann TMessager.

Ich kann also die Aussage
Zitat:
Nach dem Aufruf von Supports(..) haben wir in unserer Interface-Variable eine Referenz auf die TContainerClass -Instanz!
nicht nachvollziehen.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight

Geändert von Stevie (30. Jan 2014 um 07:32 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort

 

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:12 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz