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

[himitsu]

Delphi-Quellcode:

var 
  M: TMyClass;
  B: TSomeSystemClass;

M := TMyClass.Create;
M.SomeVal := ...; // TMyClass.SetSomeVal
TSomeSystemClass(M).SomeVal := ...; // TSomeSystemClass.SetSomeVal
S := M;
S.SomeVal := ...; // TSomeSystemClass.SetSomeVal

S := TMyClass.Create;
S.SomeVal := ...; // TSomeSystemClass.SetSomeVal
TMyClass(S).SomeVal := ...; // TMyClass.SetSomeVal

[Incocnito]

Zitat von himitsu:

Delphi-Quellcode:

var 
  M: TMyClass;
  B: TSomeSystemClass;

M := TMyClass.Create;
M.SomeVal := ...; // TMyClass.SetSomeVal
TSomeSystemClass(M).SomeVal := ...; // TSomeSystemClass.SetSomeVal
S := M;
S.SomeVal := ...; // TSomeSystemClass.SetSomeVal

S := TMyClass.Create;
S.SomeVal := ...; // TSomeSystemClass.SetSomeVal
TMyClass(S).SomeVal := ...; // TMyClass.SetSomeVal

Ich sehe das gelassen. Es sollte keinen Grund geben meine Klasse zu Casten.
Und wenn es doch einer tut muss er damit leben, dass die Aufrufe dann genau so
funktionieren, wie von der Oberklasse vorgesehen.

[himitsu]

Casten ist garnicht nötig. (siehe jeweils die ersten zwei Zeilen, ab/inkl. dem Create)

Ist wie beim TStringList.
Man kann hier überall TStrings für seine Variablen und Parameter verwenden, ohne dass es Probleme bereitet, falls man nicht auf was Spezielles von TSTringList zugreifen muss.

Wie gesagt, bei solches Arten des Überdeckens muß man dann damit rechnen, dass es gegenüber einem Überschreiben (Override) eventuell ein paar Aussetzer geben kann, wenn nicht der "genaue" Typ verwendet wird.


Muß man sicher stellen, dass sein Code "immer" ausgeführt wird, denn geht kein Weg um OVERRITE drumrum,
oder man baut z.B. Fallstricke für den Compiler ein, indem man die OOP missachtet (etwas versteckt was mal sichtbar war)
und seine Funktion unter einem anderen Namen veröffentlicht, damit es knallt, wenn jemand den falschen Typen benutzt.

Delphi-Quellcode:

type
  TMyClass = class(TSomeSystemClass)
  private
    Function GetSomeVal() : Boolean;
    Procedure SetSomeVal(const Value : Boolean);
  protected
    SomeVal;  // hier wird der Compiler sich zurecht beschweren, aber diese "Warnung" kann man ignorieren oder deaktivieren.
  public
    SomeVal2 : Boolean read GetSomeVal write SetSomeVal;
  end;

Über den OriginalTyp kann immernoch das alte SomeVal aufgerufen werden, aber ausversehn SomeVal2 über den alten Typ zu benutzen ist nicht möglich, womit man somit darauf hingewiesen wird, dass etwas nicht stimmt.