Verdeckte Eigenschaften verwenden

[Incocnito]

Hallo Leute,

ich steht gerade auf dem Schlauch.
Ich will auf die verdeckte Eigenschaft zugreifen komme aber nicht drauf, wie das geht.

Theoretisches Beispiel:

Delphi-Quellcode:

type
  TMyClass = class(TSomeSystemClass)
  private
    Function GetSomeVal() : Boolean;
    Procedure SetSomeVal(const Value : Boolean);
  public
    SomeVal : Boolean read GetSomeVal write SetSomeVal;
  end;
  
...

Function TMyClass.GetSomeVal() : Boolean;
Begin
  Result := inherited.SomeVal; // <- Geht so nicht
  DoSomeThingMore_1();
End;

Procedure TMyClass.SetSomeVal(const Value : Boolean);
Begin
  inherited.SomeVal := Value; // <- Geht so nicht
  DoSomeThingMore_2();
End;

Ich dachte ich könnte einfach mit Inherited darauf zugreifen,
aber das ist wohl nur für den aktuellen Kontext gedacht.

Weiß jemand, wie ich die Verwendung von "SomeVal" aus der Klasse
TSomeSystemClass "verhindern" kann, so dass es nur in Verbindung
mit der Prozedur "DoSomeThingMore_X()" läuft.

Die zugrundeliegende Klasse kann/will ich ja nicht ändern.

Mit freundlichem Gruß
Incocnito

[Incocnito]

Hi Frühlingsrolle!

Vielen Dank für die Hilfe.
Ironischerweise war das Lesen deines Beispiels die Hilfe zur Lösung,
auch wenn Sie nicht die eigendliche Lösung war.
Mein Fehler war einfach nur der Punkt zwischen "inherited" und "SomeVal"
in meiner "GetSomeVal"- und meiner "SetSomeVal"-Methode.
Ohne den Punkt macht er nun genau das was er soll!

Mit freundlichem Gruß
Incocnito

[Der schöne Günther]

Grade das ist der Sinn von private . Statt private solltest du dann protected nehmen, wenn abgeleitete Klassen das verwenden können sollen.

Und die Getter/Setter-Methoden kannst du bewusst noch virtual machen, wenn abgeleitete Klassen sie auch überschreiben können sollen.

[DeddyH]

Zitat von Frühlingsrolle:

Hier sollte das Beispiel dennoch funktionieren, weil die Klassen in ein und derselben Unit gegeben sind.

Aber auch nur, solange die Methoden als private und nicht als strict private deklariert wurden.

[Incocnito]

Zitat von Der schöne Günther:

Grade das ist der Sinn von private . Statt private solltest du dann protected nehmen, wenn abgeleitete Klassen das verwenden können sollen.

Und die Getter/Setter-Methoden kannst du bewusst noch virtual machen, wenn abgeleitete Klassen sie auch überschreiben können sollen.

Die ableitende Klasse ist von mir. Die abgeleitete Klasse (Basisklasse) ist unveränderbar.
In der Basisklasse ist das Feld public.
Wenn meine Klasse verwendet wird, sollen die Zehntausend anderen Methoden/Eigenschaften/...
genau so verwendet werden, aber wenn einer "SomeVal" ausließt oder ändert, soll immer auch noch was gemacht werden.
Ob jemand meine Klasse ableiten will ist mir dann im Zweifelsfall erstmal egal.

Hab' ich meine Ausgangsfrage echt so missverständlich geschrieben?

Wie gesagt, ich hatte nach "inherited" einen Punkt gemacht und mich gewundert,
was ich denn wohl falsch mache. Das war schon der ganze Fehler.

Liebe Grüße aus dem hohen Norden
Inocncito

[himitsu]

Problemchen bei dieser Art des Überschreibens.

Wenn jemand als Variable TSomeSystemClass verwendet, dann greift er auf das Original zu, da deine Überdeckung nicht bekannt ist.
Die fehlerunanfällige Lösung wäre es, wenn Getter und Setter virtual sind und direkt überschrieben werden können.

[Incocnito]

Zitat von himitsu:

Problemchen bei dieser Art des Überschreibens.

Wenn jemand als Variable TSomeSystemClass verwendet, dann greift er auf das Original zu, da deine Überdeckung nicht bekannt ist.
Die fehlerunanfällige Lösung wäre es, wenn Getter und Setter virtual sind und direkt überschrieben werden können.

Das ist mir zu hoch.
Wenn jemand direkt auf "TSomeSystemClass" zugreift (davon ein Objekt erstellt und damit arbeitet),
kann ich doch eh nichts mehr machen. Oder wie jetzt?

[Edit:]
Oder meinst du

Delphi-Quellcode:

...
var test : TSomeSystemClass;
begin
  test := TMyClass.Create();
  ...

[/Edit]

Liebe Grüße
Incocnito