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.