![]() |
AW: Attribute überschreiben
Zitat:
Dann würde ich trotzdem den Weg gehen, eine Basisklasse ohne Attribute zu erzeugen. Zusätzlich kannst Du in deiner Library noch die Standardausprägung vorhalten. Bei Ausnahmen würde ich aber wieder von der Basisklasse ableiten. Weiterhin würde ich unbedingt Standardbeschriftungen als Konstanten ablegen. Was die Mehrsprachigkeit anbelangt, würde ich zu einem guten Lokalisierungstool greifen und nicht mit den Attributen rumwerkeln. Dann musst Du nämlich bei jeder Sprachanpassung (Tippfehler o.ä.) ein neues Release bauen. Das wird irgendwann lästig. Vor allen Dingen, wenn Du (weiß ich ja nicht), noch eine Testabteilung hast, die jedes neue *Release* erst einmal 10 Tage durchtesten muss. |
AW: Attribute überschreiben
Am BusinessObject ist das aber eher falsch platziert, da man sehr oft noch zusätzliche Daten benötigt (Items in der ComboBox) oder die Daten vorher umwandeln, aufteilen, ... muss, damit diese vernünftig angezeigt werden können.
Will man das mit aller Gewalt, dann überfrachtet man das BO mit Dingen, die da eigentlich nicht hingehören. Da ist es immer ratsam eine eigene Klasse zu nehmen, die dann das BO kapselt und diesen ganzen Konvertierungs-Schnickschnack übernimmt. Diese Klasse kann man dann auch zuverlässig auf eine Handvoll Datentypen einschränken, bzw. spezielle Datentypen vorsehen, die sich gut zur Präsentation eignen. |
AW: Attribute überschreiben
Richtig, eigentlich ist es das Viewmodel, wo solche Attribute angebracht sind. Das verlagert das Problem aber nur.
|
AW: Attribute überschreiben
Zitat:
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. |
AW: Attribute überschreiben
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:
Mir jedenfalls nicht. Ist aber Geschmackssache.
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; |
AW: Attribute überschreiben
Ich glaube, du hast das LSP falsch verstanden - ich zitiere mal
![]() "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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:20 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 by Thomas Breitkreuz