Frage zu Property-Definition, RTTI liefert zwei mal gleiche Property

[s.h.a.r.k]

Hallo zusammen,

ich weiß gerade nicht wirklich, wie ich es ausdrücken soll, da ich gerade ein sprachliches (also im Bezug auf Delphi) Problem im Bezug auf folgenden Sachverhalt habe:

Delphi-Quellcode:

type
TA = class(TObject);
private
  FBlub : String;
public
  property Blub : String read FBlub write FBlub;
end;

TB = class(TA)
public
  property Blub;
end;

So, nun ist die Frage, was genau das property Blub; in der Klasse TB bewirkt. Wird die bisherige Eigenschaft überschrieben?! Ich habe es bisher einfach so hingenommen und bisher nie über Sinn und Zweck nachgedacht und prompt holt es mich ein...

Und zwar habe ich im Moment das Problem, dass wenn ich alle Properties (GetProperties, nicht GetDeclaredProperties) einer Klasse durchlaufe, RTTI mir zwei mal die gleiche Property (zumindest zwei mal den gleichen Namen) ausspuckt. Ich denke, dass sich dieses Problem mit der obigen Frage klären lässt.

[himitsu]

In deinem Beispiel im Grunde genommen nix.

Dieses kann man aber dazu nutzen, um die Sichtbarkeit von Properties zu erhöhen.

Delphi-Quellcode:

type
TA = class(TObject);
private
  FBlub : String;
protected
  property Blub : String read FBlub write FBlub;
end;

TB = class(TA)
public
  property Blub;
end;

[bernau]

Warum wird das Property in der Klasse TB noch mal public definiert. Ist doch schon Public.

(Ich weis, ist keine Antwort auf deine Frage.)

[negaH]

In der hierarischen RTTI, also ausgehend von TB bis zur Rootklasse wird die Property für die Klasse TB sehr wohl zweimal vorkommen müssen. Entscheidend dabei ist ob bei beiden gleichnamigen Properties die exakt gleichen Getter und Setter in der RTTI hinterlegt sind. Nur dann kann man von einem "überflüssigen Duplikat" ausgehen. Allerdings könntest du ja auch für die Property in Klasse TB auf andere Getter/Setter zugreifen und somit wäre funktional diese Property eben nicht mehr identisch zur Basisklasse. Und exakt das ist der logische Sinn der Frage warum der Compiler die Property in Klasse TB erneut in der RTTI kodiert egal ob es in diesem Fall sinnvoll ist oder nicht, wichtig sind alle die anderen Fälle bei denen es nicht so ist. Mal davon abgesehen das man, wie schon richtig bemerkt, die Sichtbarkeit von Properties auf diese Weise erhöhen kann.

Gruß Hagen

[s.h.a.r.k]

Zitat von bernau:

Warum wird das Property in der Klasse TB noch mal public definiert. Ist doch schon Public.

(Ich weis, ist keine Antwort auf deine Frage.)

Ich mache das, weil ich in meinem Fall noch zusätzliche Attribute zu einer Property setze.

@negaH: Danke, exakt das hat mir bisher gefehlt, habe irgendwie nicht dran gedacht gehabt. Muss dann meine RttiHelper-Klasse doch etwas optimieren, da ich diese ja mal als veröffentlichen mag. Gibt schon einige Verbesserungen vor allem bzgl. der SetValue-Methode von TRttiProperty (in meinem neuesten Blog-Eintrag hab ich darüber ja mal was geschrieben).

Insgesamt stellt sich mir dann aber auch die Frage danach, ob ich eine Property überschreiben kann. Bin noch nie auf die Idee gekommen das zu machen. Mal schauen, was ein Testprogramm dazu sagt

Danke nochmals an alle Beteiligten des Threads

[SirTwist]

wenn du zusätzliche Attribute setzen willst, solltest Du den Setter überschreiben, aber nicht die Property.

[negaH]

Zitat von SirTwist:

wenn du zusätzliche Attribute setzen willst, solltest Du den Setter überschreiben, aber nicht die Property.

Und warum so und nicht anders ?

Gruß Hagen

[s.h.a.r.k]

Das mit dem Setter verstehe ich auch nicht wirklich, da dieser ja nicht wirklich was mit dem Attribut der Property zu tun hat.

[negaH]

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