Zugriff auf Unterklasse absichern

[norwegen60]

Hallo zusammen,

ich habe folgende (vereinfachte) Klassenstruktur

Delphi-Quellcode:

  TMethode = class
  private
    FNo: Integer;
    FName: String;
  public
    property No: Integer read FNo write FNo;
    property Name: String read FName write FName;
    constructor Create;
    destructor Destroy; reintroduce;
  end;
  
  TAnalyse = class
  private
    FNo: Integer;
    FName: String;
    FMethode : TMethode;
  public
    property No: Integer read FNo write FNo;
    property Name: String read FName write FName;
    property Methode: TMethode read FMethode write FMethode;
    constructor Create;
    destructor Destroy; reintroduce;
  end;
  

  begin
    Label1.Caption := Analyse.Methode.Name;
  end;

Die Zuweisung in der letzten Zeile würde natürlich fehschlagen, wenn der Analyse keine gültige Methode zugewiesen ist. Wie fange ich diesen Fall am Besten ab:

• Erstellung einer Dummy-Methode, die im Falle des nicht Vorhandenseins der Analyse zugewiesen wird?
• Jedes mal mit
  Delphi-Quellcode:

  if assigned(Analyse.Methode) then

  überprüfen?
• Andere, elegantere Möglichkeit?

Danke
Gerd

[Der schöne Günther]

Die "elegante" Möglichkeit ist was andere Sprachen als "Elvis-Operator" oder (etwas seriöser) "Null-Propagation" kennen. Delphi hat das leider nicht.

Bleiben Möglichkeit 1 und 2: Entweder du belegst die "FMethode"-Referenz schon im TAnalyse-Konstruktor mit einer gültigen Dummy/Null-Instanz, oder du prüfst halt jedes mal. Beides ist legitim, wichtig IMO nur dass es vernünftig dokumentiert ist ob man sich drauf verlassen kann dass die Referenz niemals

Delphi-Quellcode:

nil

ist oder man gefälligst vorher prüft.

[bra]

Es gibt bei Delphi die IfThen-Funktion, die ähnlich wie der Elvis-Operator (kannte die Bezeichnung bisher gar nicht) arbeitet.

Delphi-Quellcode:

Label1.Caption := IfThen(Assigned(Analyse.Methode), Analyse.Methode.Name, '');

Ist aber kein wirklich schöner Code.

[zagota]

Zitat:

Zitat von bra (Beitrag 1377874)

Es gibt bei Delphi die IfThen-Funktion, die ähnlich wie der Elvis-Operator (kannte die Bezeichnung bisher gar nicht) arbeitet.

Delphi-Quellcode:

Label1.Caption := IfThen(Assigned(Analyse.Methode), Analyse.Methode.Name, '');

Ist aber kein wirklich schöner Code.

Der vermutlich auch nicht funktioniert, wenn Analyse.Methode NIL ist.

cu

[Der schöne Günther]

Richtig - Er würde ja erst alle Parameter auswerten (und scheitern) bevor er diese komische

Delphi-Quellcode:

IfThen

-Methode überhaupt betreten würde.

[stahli]

Man kann TAnalyse ggf. auch ein Property oder eine Funktion (Get)MethodeName spendieren, wo die Nil-Prüfung dann direkt gekapselt ist und man immer einen sinnvollen Text zurück erhält.

[Der schöne Günther]

Eine ganz andere Frage:

Delphi-Quellcode:

destructor Destroy; reintroduce;

:shock: :?:

[Wosi]

Hier gibt's einige Dinge, die man eleganter lösen könnte.

Einerseits können dich immutable objects vor dem unsauberen inneren Zustand des TAnalyse-Objekts schützen. Das würde bedeuten, dass Properties keine Set-Methode besitzen und daher nur lesend zur Verfügung stehen. Die Initial-Werte aller Properties werden dem Konstruktor per Parameter übergeben und können danach nicht mehr von außen verändert werden. Wenn beim Aufruf von TAnalyse.Create ein gültiges TMethod-Objekt übergeben werden muss und man es anschließend nicht mehr ändern kann, dann brauchst du dich mit Assigned-Checks nicht mehr herumplagen.
Das bedeutet natürlich auch: Möchtest du den Wert einer Property ändern, musst du dir ein neues Objekt erstellen. Das klingt zwar aufwendig aber es verhindert eine Vielzahl von Fehlern.
Nachdem ich vor ein paar Jahren Setter aus meinen Projekten verbannt habe, hat sich die Menge neuer Bugs erheblich reduziert. Viele Fehler entstehen durch inkonsistente interne Zustände von Objekten. Ohne Setter ist es erheblich leichter die Kontrolle zu behalten.

Außerdem könnte die Einhaltung des Laws of Demeter bei der Code-Qualität helfen. Das bedeutet: lange Aufruf-Ketten wie Analyse.Methode.Name sind zu vermeiden. In deinem Beispiel ist das nicht besonders schlimm. Wenn es aber um Methoden-Aufrufe geht, solltest du derartige Konstrukte eher vermeiden.

Zuguterletzt sollten Destruktoren mit override markiert werden und nicht mit reintroduce.

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1377879)

Eine ganz andere Frage:

Delphi-Quellcode:

destructor Destroy; reintroduce;

:shock: :?:

Das hab ich mich auch grade gefragt.

Die Fehlermeldung ist berechtig, aber anstatt den Fehler zu beheben, wird hier die Meldung deaktiviert. :freak:

[norwegen60]

Zitat:

Zitat von Der schöne Günther (Beitrag 1377879)

Eine ganz andere Frage:

Delphi-Quellcode:

destructor Destroy; reintroduce;

:shock: :?:

Die wurde hier im Hause auch schon diskutiert. Der, der diese Klassen definiert hat, meint es sei nötig.

Zitat:

Zitat von stahli (Beitrag 1377878)

Man kann TAnalyse ggf. auch ein Property oder eine Funktion (Get)MethodeName spendieren, wo die Nil-Prüfung dann direkt gekapselt ist und man immer einen sinnvollen Text zurück erhält.

Wie gesagt ist die Klasse stark vereinfacht. Bevor man zu jedem Property eine Funktion schreibt, ist ein Dummy doch einfacher. Hier stört nur, dass der Code schon eine Zeit lang lebt und es Stellen gibt, die über assigned prüfen, ob mit Methoden-Parametern weiter gemacht werden kann.

Zitat:

Zitat von Wosi (Beitrag 1377882)

Einerseits können dich immutable objects vor dem unsauberen inneren Zustand des TAnalyse-Objekts schützen. Das würde bedeuten, dass Properties keine Set-Methode besitzen und daher nur lesend zur Verfügung stehen. ...

Das wäre ein erheblicher Umbau der im Moment kaum machbar ist. Trotzdem Danke für den Tip.

[Blup]

Destructor Destroy natürlich immer "override". "reintroduce" unterdrückt zwar die Warnung des Compilers wenn "override" vergessen wurde. Das führt aber dazu, das dieser Destructor z.B. beim Aufruf von Free nicht aufgerufen wird.

Ein Beispiel für eine Lösung mit Nullobject:

Delphi-Quellcode:

  TMethode = class
  protected
    class var FNullObject: TMethode;
    class function CreateNullObject: TMethode;
    class function GetNullObject: TMethode;
  public
    class property NullObject: TMethode read GetNullObject;
  private
    FNo: Integer;
    FName: String;
  protected
    procedure SetNo(AValue: Integer); virtual;
    procedure SetName(const AValue: string); virtual;
  public
    constructor Create;
    destructor Destroy; override;
    function IsNullObject: Boolean;
    property No: Integer read FNo write SetNo;
    property Name: String read FName write SetName;
  end;

  TAnalyse = class
  private
    FNo: Integer;
    FName: String;
    FMethode : TMethode;
    function GetMethode: TMethode;
    procedure SetMethode(AValue: TMethode);
  public
    constructor Create;
    destructor Destroy; override;
    property No: Integer read FNo write FNo;
    property Name: String read FName write FName;
    property Methode: TMethode read GetMethode write SetMethode;
  end;

implementation

class function TMethode.CreateNullObject: TMethode;
begin
  Result := TMethode.Create;
end;

class function TMethode.GetNullObject: TMethode;
begin
  if not Assigned(FNullObject) then
    FNullObject := CreateNullObject;

  Result := FNullObject;
end;

procedure TMethode.SetNo(AValue: Integer);
begin
  if IsNullObject then
    Exit;

  FNo := AValue;
end;

procedure TMethode.SetName(const AValue: string);
begin
  if IsNullObject then
    Exit;

  FName := AValue; 
end;

function TMethode.IsNullObject: Boolean;
begin
  Result := (Self = FNullObject);
end;

destructor TMethode.Destroy;
begin
  if IsNullObject then
    FNullObject := nil;

  inherited;
end;

function TAnalyse.GetMethode: TMethode;
begin
  if Assigned(FMethode) then
    Result := FMethode
  else
    Result := TMethode.NullObject;
end;

procedure TAnalyse.SetMethode(AValue: TMethode);
begin
  if AValue.IsNullObject then
    FMethode := nil
  else
    FMethode := AValue;
end;

finalization
  TMethode.FNullObject.Free; // oder im class-destructor

end.

[Wosi]

Zitat:

Zitat von norwegen60 (Beitrag 1377884)

Zitat:

Zitat von Der schöne Günther (Beitrag 1377879)

Eine ganz andere Frage:

Delphi-Quellcode:

destructor Destroy; reintroduce;

:shock: :?:

Die wurde hier im Hause auch schon diskutiert. Der, der diese Klassen definiert hat, meint es sei nötig.

Ich wette er liegt falsch.
Destroy wird von TObject.Free aufgerufen und ist virtual. Mit reintroduce wird der Aufruf des neu definierten Destruktors verhindert.

[himitsu]

Und dieser neue Destructor wird ausschlichlich nur dann aufgerufen, wenn die Variable diesen Klassentyp hat, bzw. gecastet wird.

Free und Destroy über Variable/Cast eines Vorfahren ignoriert dieses Destroy dann, was ja eigentlich fast nie gewollt sein dürfte.
Wenn doch, dann benennt diesen neuen Destructor doch bitte anders.


PS: Post #11, da fehlt der Vorfahre beim NullObject.

Ableitung mit böser Prüfung im Vorfahren.

Delphi-Quellcode:

type
  TMethode = class
    ...
    function IsNullObject: Boolean; {virtual;}
  end;

  TMethodeNullObject = class(TMethodeNullObject);

function TMethode.IsNullObject: Boolean;
begin
  Result := Self is TMethodeNullObject;
end;

oder ohne Ableitung

Delphi-Quellcode:

type
  TMethode = class
    ...
    function IsNullObject: Boolean; {virtual;}
  end;

function TMethode.IsNullObject: Boolean;
begin
  Result := Self = FNullObject;
end;

[mjustin]

Zitat:

Zitat von himitsu (Beitrag 1377890)

Ginge statt diesem auch ein Marker-Interface (so kenne ich es in Java)?

Delphi-Quellcode:

type
  TMethode = class
    ...
    function IsNullObject: Boolean; {virtual;}
  end;

  TMethodeNullObject = class(TMethodeNullObject);

function TMethode.IsNullObject: Boolean;
begin
  Result := Self is TMethodeNullObject;
end;

oder ohne Ableitung

Delphi-Quellcode:

type
  TMethode = class
    ...
    function IsNullObject: Boolean; {virtual;}
  end;

function TMethode.IsNullObject: Boolean;
begin
  Result := Self = FNullObject;
end;

Z.B.

Delphi-Quellcode:

type
  INullObject = interface
[GUID]
end;

TMethodeNullObject = class(TMethodeNullObject, INullObject);


und testen dann mit 

Supports(FNullObject, INullObject);

Dadurch spart man das Deklarieren klassenspezifischer Nullobjektklassen.

[norwegen60]

Ich denke das

Zitat:

Zitat von Blup (Beitrag 1377886)

function TAnalyse.GetMethode: TMethode;
begin
if Assigned(FAnalyse) then
Result := FAnalyse
else
Result := TAnalyse.NullObject;
end;
[/delphi]

müsste

Delphi-Quellcode:

function TAnalyse.GetMethode: TMethode;
begin
  if Assigned(FMethode) then
    Result := FMethode
  else
    Result := TMethode.NullObject;
end;

heissen.

Ich verstehe allerdings nicht ganz, warum damit der Zugriff

Delphi-Quellcode:

Label1.Caption := Analyse.Methode.Name

funktionieren sollte. Der Lesezugriff auf FName erfolgt ja immer noch direkt, d.h. ohne Getter und darin enthaltener Prüfung auf IsNullObject.

Nachteil ist, dass alle Properties über Set/Get erfolgen müssen. Da erscheint ein Dummy einfacher.

[Blup]

Hab eure Anregungen und Fehlerhinweise berücksichtigt. War aus dem Stehgreif ohne Entwicklungsumgebung, da kann man sich mal vertippen.

@norweger60
Analyse.Methode liefert üer den Getter nun bei FMethode = nil das Nullobjekt zurück. Der Name ist zwar leer, aber das macht ja bei einem Label auch Sinn. Sollte ein Fehler auftreten, der Schreibzugriffe auf Properties des Nullobjekt zur Folge hat, werden diese ignoriert. So wird der Fehler nicht in andere Programmteile verschleppt.

[himitsu]

Zitat:

Zitat von mjustin (Beitrag 1377892)

Delphi-Quellcode:

type
  TMethodeNullObject = class(TMethodeNullObject, INullObject);

Dadurch spart man das Deklarieren klassenspezifischer Nullobjektklassen.

Die Klasse gibt es dennoch, aber so hätte man eine gemeinsame Prüfmethode für mehrere Klassen.

Wenn man alle NullObjekte in einen gemeinsamen Store (Liste) legt, dann könnte man auch sagen "NullObjekt ist das, was in der Liste ist" und braucht dann nur eine Objektklasse.

[norwegen60]

Zitat:

Zitat von Blup (Beitrag 1377899)

@norweger60
Analyse.Methode liefert üer den Getter nun bei FMethode = nil das Nullobjekt zurück. Der Name ist zwar leer, aber das macht ja bei einem Label auch Sinn. Sollte ein Fehler auftreten, der Schreibzugriffe auf Properties des Nullobjekt zur Folge hat, werden diese ignoriert. So wird der Fehler nicht in andere Programmteile verschleppt.

Analyse.Methode liefert ja auch NIL zurück, wenn ich sie gar nicht belegt habe. Und NIL.Name führt dann zur Exception. Oder überseh ich was?

[bra]

Zitat:

Zitat von zagota (Beitrag 1377876)

Der vermutlich auch nicht funktioniert, wenn Analyse.Methode NIL ist.

Stimmt, da bin ich auch schonmal drüber gestolpert :oops:

[Zacherl]

Zitat:

Zitat von zagota (Beitrag 1377876)

Zitat:

Zitat von bra (Beitrag 1377874)

Es gibt bei Delphi die IfThen-Funktion, die ähnlich wie der Elvis-Operator (kannte die Bezeichnung bisher gar nicht) arbeitet.

Delphi-Quellcode:

Label1.Caption := IfThen(Assigned(Analyse.Methode), Analyse.Methode.Name, '');

Ist aber kein wirklich schöner Code.

Der vermutlich auch nicht funktioniert, wenn Analyse.Methode NIL ist.

Zitat:

Zitat von Der schöne Günther (Beitrag 1377877)

Richtig - Er würde ja erst alle Parameter auswerten (und scheitern) bevor er diese komische

Delphi-Quellcode:

IfThen

-Methode überhaupt betreten würde.

Verstehe ich hier etwas falsch und

Delphi-Quellcode:

IfThen

soll nicht den ternären Operator simulieren? Wenn ich richtig liege, würde nämlich nur

Delphi-Quellcode:

Assigned(Analyse.Method)

ausgewertet - was ja vollkommen legitim ist - und dann abhängig vom Ergebnis das erste- oder zweite Argument zurückgegeben.

[TiGü]

Zitat:

Zitat von Zacherl (Beitrag 1377914)

Verstehe ich hier etwas falsch und

Delphi-Quellcode:

IfThen

soll nicht den ternären Operator simulieren? Wenn ich richtig liege, würde nämlich nur

Delphi-Quellcode:

Assigned(Analyse.Method)

ausgewertet - was ja vollkommen legitim ist - und dann abhängig vom Ergebnis das erste- oder zweite Argument zurückgegeben.

Leider nicht, es werden alle Funktion für die drei Argumente ausgeführt. Kann man auch schnell hinterherdebuggen:

Delphi-Quellcode:

program Project1;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils,
  System.Math;

var
  Res: Integer;

function GiveDecision: Boolean;
begin
  Writeln('GiveDecision');
  Result := Boolean(RandomRange(0, 1));
end;

function GiveFive: Integer;
begin
  Writeln('GiveFive');
  Result := 5;
end;

function GiveFour: Integer;
begin
  Writeln('GiveFour');
  Result := 4;
end;

begin
  try
    Res := IfThen(GiveDecision, GiveFive, GiveFour);
    Writeln('Res: ' + Res.ToString);
    Readln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;

end.

[DeddyH]

Da es ja hier um einen String geht, dürfte das IfThen aus StrUtils gemeint sein:

Zitat:

Zitat von StrUtils (Delphi Berlin)

Delphi-Quellcode:

function IfThen(AValue: Boolean; const ATrue: string;
  AFalse: string = ''): string;
begin
  if AValue then
    Result := ATrue
  else
    Result := AFalse;
end;

Das sollte doch gefahrlos anzuwenden sein wie gezeigt.

[edit] Nee, Denkfehler, es wird ja trotzdem darauf zugegriffen. [/edit]

[bra]

Es wird ja schon beim Übergeben an die Funktion ausgewertet, da kracht es schon :|

[DeddyH]

Japp, siehe mein Edit.

[Blup]

Zitat:

Zitat von norwegen60 (Beitrag 1377911)

Zitat:

Zitat von Blup (Beitrag 1377899)

@norweger60
Analyse.Methode liefert üer den Getter nun bei FMethode = nil das Nullobjekt zurück. Der Name ist zwar leer, aber das macht ja bei einem Label auch Sinn. Sollte ein Fehler auftreten, der Schreibzugriffe auf Properties des Nullobjekt zur Folge hat, werden diese ignoriert. So wird der Fehler nicht in andere Programmteile verschleppt.

Analyse.Methode liefert ja auch NIL zurück, wenn ich sie gar nicht belegt habe. Und NIL.Name führt dann zur Exception. Oder überseh ich was?

Ja, bei meinem Beispiel liefert Analyse.Methode niemals nil zurück. Sollte FMethode = nil sein, wird das NullObject zurückgegeben. Das erledigt der Getter.

[Wosi]

Zitat:

Zitat von DeddyH (Beitrag 1377917)

Da es ja hier um einen String geht, dürfte das IfThen aus StrUtils gemeint sein:

Zitat:

Zitat von StrUtils (Delphi Berlin)

Delphi-Quellcode:

function IfThen(AValue: Boolean; const ATrue: string;
  AFalse: string = ''): string;
begin
  if AValue then
    Result := ATrue
  else
    Result := AFalse;
end;

Das sollte doch gefahrlos anzuwenden sein wie gezeigt.

[edit] Nee, Denkfehler, es wird ja trotzdem darauf zugegriffen. [/edit]

Um die Auswertung von Analyse.Method.Name nur im Erfolgsfall durchzuführen, müsste man anstelle eines String-Parameters ein TFunc<String> verwenden:

Delphi-Quellcode:

function IfThen(AValue: Boolean; const ATrueFunc: TFunc<String>;
  AFalse: string = ''): string;
begin
  if AValue then
    Result := ATrueFunc()
  else
    Result := AFalse;
end;

Der Aufruf sähe dann so aus:

Delphi-Quellcode:

IfThen(Assigned(Analyse.Method), function: String begin Result := Analyse.Method.Name end);

Und da diese Schreibweise ein wenig aufwendig ist, kann man auch gleich bei

Delphi-Quellcode:

if Assigned(Analyse.Method) then 
  Label1.Caption := Analyse.Method.Name;

bleiben.

[Zacherl]

Zitat:

Zitat von bra (Beitrag 1377918)

Es wird ja schon beim Übergeben an die Funktion ausgewertet, da kracht es schon :|

Achja logisch. Zu viel C programmiert in letzter Zeit 8-)

Könnte man sich höchstens mit anonymen Methoden noch was zusammenbasteln:

Delphi-Quellcode:

class function TTernaryOp.Execute<T>(Condition: Boolean; const ATrue, AFalse: TFunc<T>): T;
begin
  if Condition then
  begin
    Result := ATrue;
  end else
  begin
    Result := AFalse;
  end;
end;

oder falls ausreichend auch:

Delphi-Quellcode:

class function TTernaryOp.Execute<T>(Condition: Boolean; const ATrue: TFunc<T>; const AFalse: T): T;

Ist natürlich alles nicht wirklich schön.

Edit: Roter Kasten?

[Uwe Raabe]

Ich will auch noch meinen Senf dazu geben :-D

Man kann dem Property Name in

Delphi-Quellcode:

TMethode

auch einen smarten Getter verpassen, dann spart man sich das Null-Objekt:

Delphi-Quellcode:

type
  TMethode = class
  private
    FName: String;
    function GetName: String;
  public
    property Name: String read GetName write FName;
  end;

function TMethode.GetName: String;
begin
  if (Self = nil) then Exit('');
  Result := FName;
end;

[norwegen60]

Zitat:

Zitat von Blup (Beitrag 1377920)

Ja, bei meinem Beispiel liefert Analyse.Methode niemals nil zurück. Sollte FMethode = nil sein, wird das NullObject zurückgegeben. Das erledigt der Getter.

Ja klar. NullObject hat mich auf NIL geleitet aber du machst ja ein

Delphi-Quellcode:

class function TMethode.CreateNullObject: TMethode;
begin
  Result := TMethode.Create;
end;

Zitat:

Zitat von Uwe Raabe (Beitrag 1377929)

Ich will auch noch meinen Senf dazu geben :-D[/DELPHI]

Damit müsste ich aber jedem Property einen "smarten Getter" verpassen und das wollte ich vermeiden

Vielen Dank
Gerd

[himitsu]

IfThen ist zwar eine Inline-Funktion und da "könnte" der Compiler das theoretisch so optimieren, dass nur der jeweilige Parameter erst später aufgelöst wird, aber das tut der leider nicht.