AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Zugriff auf Unterklasse absichern

Ein Thema von norwegen60 · begonnen am 2. Aug 2017 · letzter Beitrag vom 2. Aug 2017
Antwort Antwort
Seite 1 von 2  1 2      
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#1

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 09:53
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.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Der schöne Günther

Registriert seit: 6. Mär 2013
6.216 Beiträge
 
Delphi 10 Seattle Enterprise
 
#2

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 10:00
Eine ganz andere Frage:

destructor Destroy; reintroduce;
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.586 Beiträge
 
Delphi 12 Athens
 
#3

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 10:29
Eine ganz andere Frage:

destructor Destroy; reintroduce;
Das hab ich mich auch grade gefragt.

Die Fehlermeldung ist berechtig, aber anstatt den Fehler zu beheben, wird hier die Meldung deaktiviert.
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Blup

Registriert seit: 7. Aug 2008
Ort: Brandenburg
1.494 Beiträge
 
Delphi 12 Athens
 
#4

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 10:46
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.

Geändert von Blup ( 2. Aug 2017 um 12:24 Uhr) Grund: GetMethode korrigiert, Hilfsklasse für Nullobjekt eingespart
  Mit Zitat antworten Zitat
Wosi

Registriert seit: 29. Aug 2007
59 Beiträge
 
#5

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 10:26
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.
  Mit Zitat antworten Zitat
norwegen60

Registriert seit: 23. Dez 2007
Ort: Schwarzwald
529 Beiträge
 
Delphi 12 Athens
 
#6

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 10:38
Eine ganz andere Frage:

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

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.


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.
  Mit Zitat antworten Zitat
Wosi

Registriert seit: 29. Aug 2007
59 Beiträge
 
#7

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 10:51
Eine ganz andere Frage:

destructor Destroy; reintroduce;
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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.586 Beiträge
 
Delphi 12 Athens
 
#8

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 11:11
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;
Ein Therapeut entspricht 1024 Gigapeut.

Geändert von himitsu ( 2. Aug 2017 um 11:17 Uhr)
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.013 Beiträge
 
Delphi 2009 Professional
 
#9

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 11:34

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.
Michael Justin
habarisoft.com
  Mit Zitat antworten Zitat
norwegen60

Registriert seit: 23. Dez 2007
Ort: Schwarzwald
529 Beiträge
 
Delphi 12 Athens
 
#10

AW: Zugriff auf Unterklasse absichern

  Alt 2. Aug 2017, 11:44
Ich denke das
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 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.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:58 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz