Ich verstehe schon worauf er hinaus will. Er meint das man den Setter virtual macht und wenn man später in einer neuen abgeleiteten Klasse das Verhalten beim Setzen dieser Property verändern möchte dann überschreibt man die Setter Methode.
Allerdings
1.) Setter und Getter sind meisten privat und statisch
2.) meine ich das man das genausogut über die neue Deklaration einer gleichnamigen Property mit eigenen statisch private Setter/Getter Methoden machen kann.
Beides, sein Vorschlag und meiner, über das Überladen von Properties, sind auf Grund der Hierarchie in der Struktur der
RTTI, eben dem Fall das du festgestellt hast das diese Propety mit gleichem Namen zweimal in der Objekthierarchie vorkommt, absolut gleichwertige
OOP konforme Möglichkeiten.
Nun muß man beide Verfahren auf ihre Mächtigkeit hin vegleichen.
Bei seiner Methode muß man die Setter/Getter Methoden von Anfang an auf protected und virtual/dynamic deklarieren. Das kostet in der kompletten Objekthierarchie einen 4 oder 2 Bytes Slot in der
VMT oder DMT. Die Klassenstruktur im gesamten Baum wird also expandiert, egal ob man in den nachfolgenden abgeleiteten Klassen jemals diese, vom Programmier der Basisklasse, angestrebte Flexibilität benutzten wird oder nicht. (speziell für die
VMT gilt dies da diese immer komplett als Speicherabbild und Duplikat vererbt wird).
Macht man das aber über das Überladen der Property so entsteht folgendes Bild:
1.) Setter/Getter können weiterhin static und private sein wenn man es möchte
2.) keine Expansion der
VMT/DMT mit unnötigen Slots, somit kleinere Klassenstrukturen
3.) erst wenn es wirklich notwendig wird kann der Programmierer oder jeder Andere in einer abgeleiteten Klasse die Property überladen, weil er es auch dann benötigt
4.) der somit überzeugendste Schluß ist: der Initialentwickler der Basisklassen wird von einer Verantwortung befreit sich in diesem Fall schon von Anfang an mit allen Möglich- und Unmglichkeiten zu befassen. Man gewinnt eine zusätzliche Freiheit im Klassendesign.
Gruß Hagen