Attribute überschreiben

[Stevie]

Zitat von Dejan Vu:

Grundsätzlich ist es kein gutes OOP, eine Eigenschaft mit einer konkreten Bedeutung in einer Kindklasse zu überschreiben und ihm dabei eine andere Bedeutung zu geben ('Liskov Prinzip', das 'L' in SOLID).

Das Ändern einer Caption oder einer Eigenschaft von 10 auf 30 verletzt wohl kaum das LSP.

Einfach merken, welche Eigenschaften man überschrieben hat:

Delphi-Quellcode:

program Project104;

{$APPTYPE CONSOLE}

uses
  Controls,
  Generics.Collections,
  Rtti,
  SysUtils;

type
  CheckboxAttribute = class(TCustomAttribute)
    constructor Create(const caption: string; X, Y: Integer);
  end;

constructor CheckboxAttribute.Create(const caption: string; X, Y: Integer);
begin
end;

type
  TBaseClass = class(TControl)
  private
    FEigenschaft1: Boolean;
  published
    [Checkbox('Ich bin die Beschriftung',10,10)]
    property Eigenschaft1: Boolean read FEigenschaft1 write FEigenschaft1;
  end;

  TChildclass = class(TBaseClass)
  private
    FEigenschaft2: Boolean;
  published
    [Checkbox('Now i am an english caption at different position',20,20)]
    property Eigenschaft1;
    [Checkbox('I have a second property',30,30)]
    property Eigenschaft2: Boolean read FEigenschaft2 write FEigenschaft2;
  end;

var
  props: TDictionary<string,Boolean>;
  ctx: TRttiContext;
  t: TRttiType;
  p: TRttiProperty;
  a: TCustomAttribute;
begin
  props := TDictionary<string,Boolean>.Create;
  t := ctx.GetType(TChildclass);
  for p in t.GetProperties do
  begin
    if props.ContainsKey(p.Name) then
      Continue
    else
      props.Add(p.Name,True);
    for a in p.GetAttributes do
      if a is CheckboxAttribute then
        Writeln(p.Parent.Name + ' ' + p.ToString);
  end;
  Readln;
end.

[Dejan Vu]

Wieso nicht? Ich überschreibe/ändere das ursprüngliche Bedeutung. Ob dies nun zu einem veränderten Verhalten oder Darstellung (was ist daran kein Verhalten?) führt, ist -streng genommen- irrelevant.

Gefällt Dir das?

Delphi-Quellcode:

Type
  TBaseClass = class
    Function Foo : String; Virtual;
  end;

  TDerivedClass = class (TBaseClass)
    Function Foo : String; Override;
  end;

Function TBaseClass.Foo: String;
Begin
  Result := 'Foo';
End;

Function TDerivedClass.Foo : String;
Begin
  Inherited; // Ob mit oder ohne, wurscht.
  Result := 'Bar';
End;

Mir jedenfalls nicht. Ist aber Geschmackssache.

[Stevie]

Ich glaube, du hast das LSP falsch verstanden - ich zitiere mal Wikipedia:
"Es besagt, dass ein Programm, das Objekte einer Basisklasse T verwendet, auch mit Objekten der davon abgeleiteten Klasse S korrekt funktionieren muss, ohne dabei das Programm zu verändern."

Die Anzeige einer anderen Caption oder Position einer Checkbox ist somit keine Verletzung.

Dein Beispiel ist Nonsense denn hier ergibt sich keine Funktionsveränderung sondern bloß ein anderer Rückgabewert. Eine veränderte Funktionsweise ergäbe sich dadurch, dass irgendwo jemand auf Foo oder Bar abprüft und dementsprechend was anderes ausführt. Da man aber nicht die Spezifikation der Funktion Foo kennt (was soll die machen? - und nein, die soll "Foo" zurückliefern ist wohl kaum eine realistische Spec, dann hätte man sie nicht virtual gemacht), kann hier keiner Sagen, ob LSP verletzt wurde oder nicht.