Interface um Componenten-Properties zu verallgemeinern?

[Leuselator]

Nach dem Anlesen der Links aus diesem Thread kommt mir nun die Idee, Interfaces zu benutzen, um die Properties meiner eigenen Komponenten leichter handhabbar zu machen. Also dachte ich:

Delphi-Quellcode:

type 
  ILsAssociate = Interface
    ['{9D77B5ED-5C4D-4725-BFC6-3089D57F218C}']
    function  GetAsso: TLsParent;
    procedure SetAsso(const Value: TLsParent);
    property Associate: TWincontrol read GetAsso write SetAsso;
  end;

  TLsDummy = class(TCustomControl,ILsAssociate)
  private
    FAssociate        : TWincontrol;
  protected
    procedure SetAsso(const Value: TWincontrol ); // implem. für Interface
    function  GetAsso            : TWincontrol;   // dto.
    ...
  end;

  TLsDummyUser = Class(TPanel)
  private
    FEdit  : TEdit;
    FDummy : TLsDummy;
  protected
  public
    constructor Create(AOwner : TComponent); override;
  published
  end;

implementation

TLsDummyUser.Create(AOwner : TControl);
begin
  inherited;
  FEdit := TEdit.Create(self);
  FDummy := TLsDummy.Create(self);
  FDummy.Associate := FEdit; // <--- und genau das macht er nicht
  ...
end;

hmm - irgendwie schnuckt das also nicht so - wer kann mich erleuchten?

[sakura]

Versuche mal folgende Änderung:

Code:

[...]
  TLsDummyUser = Class(TPanel)
  private
    FEdit  : TEdit;
    FDummy : [color=#ff0000]ILsAssociate[/color];
  protected
  public
    constructor Create(AOwner : TComponent); override;
  published
  end;
[...]

...:cat:...

[Leuselator]

Leider bringt mich das in teufels Küche ( funktioniert trotzdem nicht) weil
1. er das Property Associate immer noch nicht kennen mag
2. Ich mit dem Objekt TLsDummy 'ne Menge so Objekt-Sachen veranstalte (z.B. WndProc von TEdit capturen etc.) und (jetzt kommt Halbwissen:) ein einmal zum Interface gewordenes Object ja nicht wieder zum Object gemacht werden darf? :gruebel:

[sakura]

Zitat:

Zitat von Leuselator

1. er das Property Associate immer noch nicht kennen mag

Das verwundert mich jetzt - aber es ist zu spät, Delphi ist schon aus :mrgreen:

Zitat:

Zitat von Leuselator

ein einmal zum Interface gewordenes Object ja nicht wieder zum Object gemacht werden darf?

Nicht ganz korrekt. Es kann aber zu Komplikationen kommen, wenn Du die letzte Referenz auf das Interface verlierst (Stichwort: automatische Refernzähler) ;-)

...:cat:...

[sakura]

Noch einen Fehler gefunden :roll:

Code:

  ILsAssociate = Interface
    ['{9D77B5ED-5C4D-4725-BFC6-3089D57F218C}']
    function  GetAsso: TWinControl;
    procedure SetAsso(const Value: TWinControl);
    property Associate: [color=#ff0000]TWincontrol[/color] read GetAsso write SetAsso;
  end;

...:cat:...

[Jens Schumann]

Moin Leuselator,
versuche es mal mit:

1. ILsAssociate (FDummy).Associate := FEdit;

2. (FDummy as ILsAssociate ).Associate:=FEdit;

[Leuselator]

@Jens: Das geht natürlich - nur ist dann der ganze denkbare Vorteil dahin - hoffte ja eben die vom Interface geerbten Properties wie ganz normal in der Komponente deklarierte verwenden können (z.B. auch im OI) und nur die jeweiligen Set- und Get-Methoden in der jew. Komponente deklarieren zu müssen.

Jemand mit Ideen/Erläuterungen dazu?

Gruß

[Jens Schumann]

Hallo Leuselator,
ich bin mir nicht sicher was Du genau erreichen möchtest.
Aber der folgende Code wird von meinem D5 geschluckt.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  extctrls, stdctrls;

type
  ILsAssociate = Interface 
    ['{9D77B5ED-5C4D-4725-BFC6-3089D57F218C}'] 
    function  GetAsso: TWincontrol;
    procedure SetAsso(const Value: TWincontrol); 
    property Associate: TWincontrol read GetAsso write SetAsso; 
  end; 

  TLsDummy = class(TCustomControl,ILsAssociate)
  private 
    FAssociate        : TWincontrol; 
  protected 
    procedure SetAsso(const Value: TWincontrol ); // implem. für Interface 
    function  GetAsso            : TWincontrol;   // dto. 
  end; 

  TLsDummyUser = Class(TPanel) 
  private 
    FEdit  : TEdit; 
    FDummy : ILsAssociate; 
  protected 
  public 
    constructor Create(AOwner : TComponent); override; 
  published 
  end; 

  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private
    { Private-Deklarationen }
    FDummySUer : TLsDummyUser;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

{ TLsDummy }

function TLsDummy.GetAsso: TWincontrol;
begin
  Result:=FAssociate;
end;

procedure TLsDummy.SetAsso(const Value: TWincontrol);
begin
  FAssociate:=Value;
end;

{ TLsDummyUser }

constructor TLsDummyUser.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FEdit:=TEdit.Create(Self);
  FDummy:= TLsDummy.Create(Self);
  FDummy.Associate:=FEdit;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  FDummySUer:=TLsDummyUser.Create(self);
  FDummySUer.Parent:=Self;
end;

end.

Hier ist FDummy als ILsAssociate deklariert.

Delphi-Quellcode:

TLsDummyUser = Class(TPanel)
  private
    FEdit  : TEdit;
    FDummy : ILsAssociate;
  protected
  public
    constructor Create(AOwner : TComponent); override;
  published
  end;

[Leuselator]

Ich muß erstmal 'ne Mütze Schlaf nehmen, vorab aber noch das:

Ich meine, das im DummyUser nicht als ILsAssociate deklarieren zu können, da ich innerhalb des DummyUser an eine ganze Reihe von Prozeduren und Eigenschaften des Dummy heranmuß, die mit dem Interface nichts zu tun haben und dort auch nicht reinkönnen. (?!)

Was ich eigentlich vorhabe: Ich habe ein ziemlich umfangreiches Package mit eigenen Komponenten.
Dort habe ich mir nun eine herausgegriffen und ein Property vom Typ TWinControl durch ein Interface ersetzen wollen. In der gleichen Unit sind ein ganzer Sack von zusammengesetzten Komponenten enthalten, die von genau dieser Komponente kräftigen Gebrauch machen. Und in deren Create's setze ich dann diese nunmehr umgewandelte Eigenschaft. Wenn ich also nun die Sache so angehe, wie im 1. Post gezeigt, so läßt sich das Package nicht mehr compilieren, da der Compiler die nun vom Interface geerbte Eigenschaft in den Konstruktoren der anderen Klassen, die von der umgewandelten Komponente gebrauch machen wollen, nicht mehr kennt.

Der Vorteil wäre, dass ich bei sich ähnlichen Komponenten, mit ähnlichen Eigenschaften aber verschiedenen Vorfahren, in Komposit-Komponenten, die ihrerseits all diese ähnlichen Komponenten verwenden Bearbeitungsroutinen wie:

Delphi-Quellcode:

procedure VerpassMal(DemDingHier : ILsAssociate; DieEigenschaft : TWincontrol);
begin
  DemDingHier.Associate := DieEigenschaft;
end;

verwenden könnte (ohne ewiges abgefrage nach Klassentyp etc.);
Und das wär dann wirklich eine enorme Arbeitsersparnis für mich.
Gruß

[choose]

Hallo Leuselator,

Interface-Properties können nicht im OI angezeigt werden. Darüber hinaus würdest uU Probleme mit der impliziten Referenzzählung bekommen, wenn Du Aggregationen oder Kompositionen herstellen möchtest.
Ein Beispiel: Es ist zwar folgendes möglich

Delphi-Quellcode:

type 
  TMyClass = class
  private
    FAggregate: TMyAggregatedClass;
    function GetAggregate: IMyAggregate;
  public
    property Aggregate: IMyAggregate
      read  GetAggregate;
  end;

function TMyClass.GetAggregate: IMyAggregate;
begin
  Result:= FAggregate as IMyAggregate; //as is optional
end;

Achtung: Sollte TMyAggregatedClass von TInterfacedObject oder einer ähnlichen Klasse mit automatischen Destructoraufruf bei RefCount==0 geerbt worden sein, ist dieser Zugriff durch einen Zusätzlichen Aufruf von _AddRef bzw. _Release im Constructor/Destructor von TMyClass zu "sichern", weil ein Klient mit Code dieser Art

Delphi-Quellcode:

myAggregate:= myObject.Aggregate;
myAggregate:= nil; //implicit call of myAggregate._Release

uU das Objekt TMyClass.FAggregate freigibt und so eine ungültige Invariante von TMyClass provoziert...

Eine Setter, wie Du ihn zu wünschen scheinst, also

Delphi-Quellcode:

type
  TMyClass = class
  //..
    procedure SetAggregate(const AnAggregate: IMyAggregate);

ist schon vom Ansatz her sinnlos, wenn Du auf spezielle Methoden von konkreten Klassen (hier: TMyAggregatedClass), die IMyAggregate implementieren, zugreifen möchtest (das zumindest habe ich aus Deinem Posting gelesen).


Falls Dein eigentliches Problem die ständigen Casts bei Klassen sind, könntest Du es mit dem visitor pattern oder dem adaptor pattern (GoF) auch ohne Interfaces hinbekommen.

Vielleicht habe ich Dein Problem aber auch nicht ganz verstanden, könntest Du ggf ein gezieltes Bsp skizzieren?