überkreuzender Bezug von Units .. kleiner Workaround

[stoxx]

Habe eine recht schöne Lösung gefunden, wie man trotz nicht gestattetem überkreuzenden Bezug von zwei Units, diese Geschichte schön umgehen kann, ohne ständig Casts durchzuführen ...

Ziel. Zwei klassen brauchen im Klassenmodell eine gegenseitige Referenz aufeinander, befinden sich aber in verschiedenen Units.. in anderen Sprachen ja nicht so das Problem, in delpi aber nicht möglich.....

Delphi-Quellcode:

TClassA = class(TObject)
  linkClassB : TClassB;
end;


TClassB = class(TObject)
  linkClassA : TClassA;
end;

Lösung ...

Delphi-Quellcode:

TClassA = class(TObject)
  linkClassB : TClassB;
end;


TClassB = class(TObject)
  _linkClassA : TObject;
end;

man speichert in _linkClassA die Referenz ab ... und greift nur noch über properties einer ClassHelper Klasse auf diese Referenz zu..

diese befindet sich aber NUR im Implementationteil der Unit, damit ist ein quasi überkreuzender Bezug von Units möglich..

Delphi-Quellcode:

implementation

uses UnitClassA;

type
  TConvertHelper = class helper for TClassB
  private
    function Get_linkClassA: TClassA;
    procedure Set_LinkClassA(const Value: TClassA);
  published

    property LinkClassA : TClassA read Get_LinkClassA write Set_LinkClassA;
  end;


//==============================================================================


function TConvertHelper.Get_LinkClassA: TClassA;
begin
  result := TClassA(_linkClassA);
end;
//==============================================================================
procedure TConvertHelper.Set_LinkClassA(const Value: TClassA);
begin
  _linkClassA := Value;
end;

und jetzt kann man in irgendeiner Methode von TClassB wunderschön mit

Delphi-Quellcode:

self.linkClassA

auf das Object zugreifen, ohne ständig rumcasten zu müssen :-)

[Dezipaitor]

Ok und in welcher Delphiversion funktioniert das?

[hoika]

Hallo

http://delphi.about.com/od/delphifor...asshelpers.htm


also Delphi.Net: D2005/2006 (?) aufwärts.


Heiko

[Dezipaitor]

Also in kleineren Versionen, überprüfe ich mit "is" bei "write property" ob es die korrekte Klasse ist.

Delphi-Quellcode:

property Xy : TObject read GetXy write SetXy;

procedure ...SetXy(Xy : TObject);
begin
  if not (Xy is TMyClass) then
    raise ....
end;

Ich weiß jedoch nicht, ob es auch für abgeleitete Klassen funktioniert. Ich könnte mir es aber vorstellen.

[stoxx]

also sowohl in .NET als auch unter Win32 funktioniert das.
Ab Delphi 2005

[Hansa]

Zitat:

Zitat von stoxx

..Ziel. Zwei klassen brauchen im Klassenmodell eine gegenseitige Referenz aufeinander, befinden sich aber in verschiedenen Units..

Dann ist das Klassenmodell in 90 % der Fälle falsch. Lerne besser programmieren und spiele nicht so viel Billard. :mrgreen:

Zitat:

in anderen Sprachen ja nicht so das Problem, in delpi aber nicht möglich.....

Unser Ober-Schwuchtel würde dazu sagen : Und das ist auch gut so. :mrgreen:

Im Ernst : glaube nicht, dass ich solch ein Konstrukt in zig-Programmen verwenden MUSS. Es gibt keins. 8)

[mkinzler]

Zitat:

Im Ernst : glaube nicht, dass ich solch ein Konstrukt in zig-Programmen verwenden MUSS. Es gibt keins. Cool

Unter Win32 vielleicht nicht, aber unter .Net ist dies ein weitverbreitetes Konzept, vorallem bei den neueren Techniken

[alzaimar]

Zitat:

Zitat von Hansa

Unser Ober-Schwuchtel würde dazu sagen : ... :mrgreen:

Ihr Saarländer müsst grad reden, ihr mit Eurem narzißtischen Hobbit. :mrgreen:

Äh?

Delphi-Quellcode:

Type
  TClassA = Class;
  TClassB = Class;
 ...
  TClassA = Class
    fRefB : TClassB;
  End;
  TClassB = Class
    fRefA : TClassA;
  End;

Oder hab ich was verpasst? :gruebel:

[uligerhardt]

Zitat:

Zitat von alzaimar

Oder hab ich was verpasst? :gruebel:

Ja:

Zitat:

Zitat von stoxx

Ziel. Zwei klassen brauchen im Klassenmodell eine gegenseitige Referenz aufeinander, befinden sich aber in verschiedenen Units..

Hatte aber beim ersten Lesen den gleichen Gedanken. Zum Glück konnte ich meinen Reflex zu posten noch rechtzeitig unterdrücken. :)

Uli.

[alzaimar]

Ah. Na dann ... Ist die Aufteilung in Units falsch. Beide Klassen gehören, da untrennbar miteinander verbunden, auch zusammen.