Hier nun eine interessante Methode, zirkuläre Referenzen mit Class Helpern noch einmal neu anzugehen
Wenn ich das Thema ClassHelper richtig verstanden habe, habe ich doch durch die ClassHelper eine THund-"
PseudoKlasse" in der folgenden Form
Delphi-Quellcode:
type
THund = class
private
function GetBesitzer: THundebesitzer; //aus ClassHelper
procedure SetBesitzer(const Value: THundebesitzer);//aus ClassHelper
protected
besitzer_uncasted: TObject;
public
name: String;
property besitzer: THundebesitzer read Getbesitzer write Setbesitzer;//aus ClassHelper
end;
Ich kann also innerhalb von THund auf den Besitzer entweder über das property direkt zugreifen oder über das ungecastete Objekt, wobei ich dann jedes Mal casten muss?
Was mich dabei stören würde, wäre die Tatsache, dass ich im Setter / Getter des properties keine zusätzliche Logik unterbringen darf (von dem Cast einmal abgesehen), wenn ich nicht will, dass diese zusätzliche Logik bei jeder Verwendung des properties ausgelöst wird.
In dem Beispiel vielleicht jetzt schwerer einsichtig, aber manchmal muss/möchte man zwischen einem Zugriff von innerhalb und außerhalb der Klasse unterscheiden (z.B. wenn man zusätzlich Aktionen durchführen möchte, wenn "von außen" (wozu properties
imho gedacht sind) auf das Objekt zugegriffen wird).
Delphi-Quellcode:
procedure THundeHelper.SetBesitzer(const Value: THundebesitzer)
begin
if Assigned(value) then
begin
besitzer_uncasted := value;
if value.name = "Der schöne Günther" then
//schlabbereNeuenBesitzerAb
else
//knurreNeuenBesitzerAn
end;
end;
Wenn ich nun will, dass die Namensabfrage des neuen Besitzers nur stattfindet, wenn ich den Benutzer von außen setze und nicht von innerhalb der Klasse THund, dann würde der Zugriff von innerhalb nur über das ungecastete Object (das ich dann casten muss) und der Zugriff von außen über das property stattfinden müssen.
Oder bringt man in Settern/Gettern sowieso keine zusätzliche Logik unter? Ist das schlechter Programmierstil?
Ich hoffe, ich konnte meine Gedanken halbwegs klar formulieren