Auf private Variable zugreifen

[Andreas L.]

z. B. so:

Delphi-Quellcode:

  TfrxBarcode2DView = class(TfrxView)
  private
    FBarCode: TfrxBarcode2DBase;
  published
    property BarCode: TfrxBarcode2DBase read FBarCode;
    // wenn der Wert nicht nur ausgelesen sondern auch
    // verändert werden soll, dann kann oder muss noch ein Setter angegeben werden
    property BarCode: TfrxBarcode2DBase read FBarCode write SetBarCode;
    // Siehe ein Tutorial zu Klassen & deren Eigenschaften...
  end;

  ...

// Beispiel für den Zugriff/Aufruf:
procedure TForm1.Button1Click(Sender: TObject);
var
  2DView: TfrxBarcode2DView;
begin
  2DView := TfrxBarcode2DView.Create;  
  try
    // Zugriff auf eine Funktion 
    2DView.BarCode.FuncXYZ();
  finally
    FreeAndNil(2DView); 
  end;
end;

[DeddyH]

Wenn ich es richtig verstanden habe, kann man das Gewünschte damit aber nicht errreichen. Man hat zwar Zugriff auf FBarCode, aber der hat mit dem Feld in der Elternklasse nichts zu tun. Nicht richtig gelesen, das war ja eine Erweiterung der bestehenden Klasse und keine Ableitung.

[himitsu]

Böse casten geht, aber man muß aufßassen, daß sich nicht verschiebt (beim nächsten Update).


Über die erweiterte RTTI erhält man auch Zugriff auf private Felder (solange das in der entsprechenden Unit/DLL nicht deaktiviert wurde).
Ob es hilbt ... k.A. da man die eigene DelphiVersion als Streng Geheim einstuft.

Zitat:

Wie manche am Quellcode schon erkennen ist es der FastReport Sourcecode, weswegen Änderungen an der Deklaration an dieser Stelle für mich ausgeschlossen sind.

Wieso?

Wir haben auch FastReport, inkl. der QuellCodes und da wir die Bibliotheken selber kompilieren, können wir da auch beliebig etwas ändern. (man muß nur beim Upgrade die Änderung wieder einbauen, falls der Bug nicht behoben wurde. )

[Daniel]

Ich löse sowas gern über einen Class-Helper. Zumindest mit XE7 kann man damit herrlich in fremden privaten Feldern herumwurschteln.
Die Code-Vervollständigung wird Dir die privaten Felder nicht anzeigen, der Compiler hingegen kommt gut damit klar.

[Dejan Vu]

Na ja, was hier propagiert wird, ist ja eigentlich: "Scheiß auf OOP". Die Frage lautet ja eigentlich: Wieso meint der TE, an das private Feld zu müssen? Meistens geht es auch anders.

[Der schöne Günther]

Zitat von Daniel:

Ich löse sowas gern über einen Class-Helper.

Das. In jeder Hinsicht besser als diese schrecklichen Interposer oder "Cracker"-Klassen.

Zitat von Dejan Vu:

Die Frage lautet ja eigentlich: Wieso meint der TE, an das private Feld zu müssen? Meistens geht es auch anders.

Die Antwort darauf hat er im letzten Absatz selbst gegeben.

[Sherlock]

Das ist der Grund war ich private nicht mag, protected hat weitestgehend den selben Effekt, man darf die aber ererben.

Sherlock

[DeddyH]

Das Feld selbst privat zu machen ist IMO durchaus in Ordnung, man kann sich aber überlegen, Getter und Setter unter protected zu deklarieren.

[JasonDX]

Ob/Wann man private verwendet hängt davon ab, welche Garantien man für dieses Feld geben und erwarten will. Wenn ich private member deklariere, dann in der Annahme, dass meine Klasse, und NUR meine Klasse diese liest und bearbeitet. Wenn ich also einen privaten String phoneNumber habe, und den in meiner Klasse nur mit einem bestimmten Format fülle, gehe ich im Rest der Klasse davon aus, dass dieser String ein bestimmtes Format hat.
Wenn nun andere Klassen diesen Wert schreiben, habe ich diese Garantie nicht mehr. Deswegen: Schreibe nie private Member von anderen Klassen. Die Klasse selbst erwartet u.U. bestimmte Konventionen, und hat ein undefiniertes Verhalten wenn diese Konventionen nicht eingehalten werden.
Das selbe geht in die andere Richtung: In einem kleinen Update ändere ich das Format dieses Strings. Das Update kann schleichend kommen - es beinhaltet keine Veränderung des APIs, und interessiert auch keinen außerhalb. Es ist schließlich das persönliche private member der Klasse. Wenn nun aber eine andere Klasse diesen Wert liest, und annimmt, dass der String ein bestimmtes Format hat, bringt diese Änderung ein undefiniertes Verhalten hervor, weil Annahmen, die für dieses Feld getroffen wurden, nicht mehr gelten.

Wenn man bspw. einen von außerhalb zugänglichen Getter setzt (sei es durch Private und Kindklassen), dann setzt man bestimmte Garantien für das Feld, die ein einfaches Ändern nicht mehr erlauben, bzw. der Getter entsprechende Umwandlung o.ä. vollzieht. Er ist aber Teil des APIs und muss damit den dokumentierten Anforderungen genügen. Ebenso andersrum: hat man einen von außerhalb zugänglichen Setter, können dafür Erwartungen definiert werden, die evt. auch im Setter überprüft werden (bspw. dass der String in einem bestimmten Format sein soll)
Der wichtigste Punkt ist: Diese Erwartungen und Garatien sind dann dokumentiert, und können(/sollten) sich nicht ohne weiteres von einen Tag auf den nächsten ohne Ankündigung ändern. Das gilt nicht für private member.

Kurzum: Private hat seine Daseinsberechtigung, und sollte auch nicht durch Tricks/Hacks umgangen werden. Es endet in einem Haufen Dung in der Codebase.

[Elrond]

Ich weiß nicht inwiefern das jetzt passt.
Aber ich musste auch mal auf ein privat Feld zugreifen und zwar wollte ich damals von TField den TFieldType zur Laufzeit ändern ohne es in jeden Formular anzupassen. Das ganze habe ich über die RTTI realisiert, dass klappt soweit ich weiß nur bei private Feldern die nicht strict private sind.

Delphi-Quellcode:

procedure ChangeProperty(Sender: TObject);
  var
    Context                             : TRttiContext;
    RttiField                           : TRttiField;
    RttiValue                           : TValue;
  begin
    RttiField := Context.GetType(TField).GetField('FDataType');
    RttiValue := TValue.FromOrdinal(TypeInfo(TFieldType), 24); //24 ftWideString

    RttiField.SetValue(Sender, RttiValue);
  end;