Zugriff auf Private Variable aus abgeleiteter Klasse aus fremder Unit

[relocate]

Hallo,

über http://www.delphipraxis.net/102890-s...variablen.html bin ich auf das hier http://hallvards.blogspot.de/2004/06...te-fields.html gekommen.

Hier mißfällt mir etwas das OOP Konzept.
Um die Ursprungsklasse mit neuen Funktionen zu erweitern leite ich sie in einer neuen Unit ab, damit die Erweiterung möglich ist, bräuchte ich aber Zugriff auf dort als private deklarierte Variablen. Warum hat eine abgeleitete Klasse nicht vollen Zugriff auf die "Oberklasse". Vor allem, weshalb geht es innerhalb der gleichen Unit und in einer Fremden Unit nicht (strict private mal außen vor, spielt in der Version keine Rolle).

Den Hack zu nutzen halte ich für fragwürdig, auch wenn er hier in D5/D6 funktioniert, aber laut Blogkommentar funktioniert er nicht mehr in einer neueren Delphi Version (kann das jemand bestätigen) was eigentlich logisch ist, schließlich sollte es ja private sein (warum auch immer).

Ist jetzt kein Problem der Delphi Praxis, aber in dem Tutorial http://www.delphi-treff.de/object-pascal/vererbung/ steht, dass die Nachfahren alles vom Vorfahren erben, was in dem Beispiel mit TMensch und TBerufstätig etc. ja nur innerhalb der selben Unit gelten würde nach dem Konzept (probiert habe ich es noch nicht) also ist die Aussage ja insofern falsch, als dass sie ja nach dem Beispiel nur innerhalb der gleichen Unit funktioniert, was man ja auch mal schreiben könnte.

Gruß relocate

PS.: Im wesentlichen geht es darum, ob mal jemand testen kann, ob der Hack in späteren Delphiversionen noch funktioniert und wenn nicht, was man dann machen kann.

[Sir Rufo]

Was du in den abgeleiteten Klassen benötigst, musst du im

Delphi-Quellcode:

protected

Abschnitt deklarieren.

Warum das OOP Konzept jetzt missfällt, weil man es falsch benutzt ist mir ein Rätsel?

[Bernhard Geyer]

Zitat:

Zitat von relocate (Beitrag 1203649)

PS.: Im wesentlichen geht es darum, ob mal jemand testen kann, ob der Hack in späteren Delphiversionen noch funktioniert und wenn nicht, was man dann machen kann.

Da wir nicht Hellsehen können ob der Compiler(entwickler) hier irgendwann andere Strukturen verwendet und welche das sein werden ist hier keine Aussage möglich.

[relocate]

Zitat:

Zitat von Sir Rufo (Beitrag 1203655)

Was du in den abgeleiteten Klassen benötigst, musst du im

Delphi-Quellcode:

protected

Abschnitt deklarieren.

Warum das OOP Konzept jetzt missfällt, weil man es falsch benutzt ist mir ein Rätsel?

Das ich das so tun müsste, ist mir klar, aber was soll ich machen, wenn der ursprüngliche Programmierer der Unit das nicht so vorgesehen hat für die Erweiterung aber notwendig ist. Ich könnte natürlich die ursprüngliche Unit bearbeiten, was in diesem Fall aufgrund der vorhandenen Source möglich wäre, aber eben die Original Unit möchte ich nicht verändern und so ist es doch auch bei OOP gedacht, dachte ich, durch Ableiten die Ursprungsklasse um neue Funktionen erweitern.

Was ich eben hier nicht verstehe, wenn man die Klasse so wie sie ist nutzt, dann macht das private durchaus sinn, dass man diese Variablen von außen nicht einfach manipuliert, wenn man sie aber durch Ableiten erweitern möchte, dann muss man doch eigentlich vollen Zugriff auf die Ursprungsklasse haben. In diesem Fall hätte ja der ursprüngliche Programmierer OOP nicht verstanden, oder gemeint, diese Klasse muss man nicht mehr erweitern, man kann ja den Source selbst ändern (so hat er das auch vorgesehen, aber das ist in meinen Augen eben kein OOP).

Wobei hier das nur die Randproblematik ist, also vielen Dank für die Erklärung (die unnötig war).

[relocate]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1203657)

Zitat:

Zitat von relocate (Beitrag 1203649)

PS.: Im wesentlichen geht es darum, ob mal jemand testen kann, ob der Hack in späteren Delphiversionen noch funktioniert und wenn nicht, was man dann machen kann.

Da wir nicht Hellsehen können ob der Compiler(entwickler) hier irgendwann andere Strukturen verwendet und welche das sein werden ist hier keine Aussage möglich.

Womit hier aber spätere Versionen als die angegebenen D5/D6 gemeint waren die also mit D7, D8 , D200X, DXE 1 - 3 schon existieren, also zu Testen wären.

[Blup]

Die Abschnitte public und published definieren die Schnittstelle für den Entwickler, der eine Komponente verwenden möchte. Der protected Abschnitt erweitert diese Schnittstelle für Entwickler, die von diese Klasse ableiten wollen. Eigentlich sollten auch spätere Versionen dieser Klasse immer mindestens die einmal veröffentlichten Properties und Methoden unterstützen.

Wenn der Entwickler es für notwendig hält, kann sich im Abschnitt private dagegen von Version zu Version alles ändern.

Im Prinzip ist ein Hack für den Zugriff auf private Felder immer nur für die Versionen gültig, für die er auch erstellt wurde. Eine Garantie für zukünftige Versionen kann es nicht geben.
Auf bekannte Änderungen in bestimmten Versionen kann man aber mit bedingter Kompillierung reagieren.

Delphi-Quellcode:

interface

uses
  Graphics;

type
  TMyIcon = class(TIcon)
  private
    function GetImage: TIconImage;
    procedure SetImage(Value: TIconImage);
  public
    property Image: TIconImage read GetImage write SetImage;
  end;

implementation

uses
  Types;

type
  THackIcon = class(TGraphic)  // Ableitung von der selben Klasse wie TIcon
  public
{$IFDEF VER180}
    // hier Felder die nur in dieser Version definiert sind
{$ENDIF}
    FImage: TIconImage;        // Felder in der selben Reihenfolge, Typ, Anzahl
    FRequestedSize: TPoint;
  end;

function TMyIcon.GetImage: TIconImage;
begin
  Result := THackIcon(Self).FImage;
end;

procedure TMyIcon.SetImage(Value: TIconImage);
begin
  THackIcon(Self).FImage := Value;
end;

[relocate]

Zitat:

Zitat von Blup (Beitrag 1203661)

Die Abschnitte public und published definieren die Schnittstelle für den Entwickler, der eine Komponente verwenden möchte. Der protected Abschnitt erweitert diese Schnittstelle für Entwickler, die von diese Klasse ableiten wollen. Eigentlich sollten auch spätere Versionen dieser Klasse immer mindestens die einmal veröffentlichten Properties und Methoden unterstützen.

Ok, das ist verständlich als reiner Anwender (auch wenn man Entwickler ist) der Komponente soll man gefälligst die Schnittstellen nutzen die vorgesehen sind. Das ist jetzt eben die Schwierigkeit und da ist es dann quasi vorbei mit der OOP wenn man eben kein Zugriff auf notwendige Daten hat, weil nicht vorgesehen.

Zitat:

Zitat von Blup (Beitrag 1203661)

Wenn der Entwickler es für notwendig hält, kann sich im Abschnitt private dagegen von Version zu Version alles ändern.

Gut, dass es interne Variablen geben muss, die die innere Funktion Gewährleisten okee, aber dass es keine ordentliche Möglichkeit gibt auf funktionelle Variablen zu zugreifen deren Manipulation für eine Erweiterung notwendig sind nur weil der Komponentenersteller das "fälschlicherweise" als private deklariert hat. Wobei ich hier jetzt eigentlich keine Grundsatzdiskussion lostreten wollte. Die Komponente wie sie ist wurde einfach nicht so programmiert, dass sie mittels OOP erweitert werden kann, fertig.

Zitat:

Zitat von Blup (Beitrag 1203661)

Im Prinzip ist ein Hack für den Zugriff auf private Felder immer nur für die Versionen gültig, für die er auch erstellt wurde. Eine Garantie für zukünftige Versionen kann es nicht geben.
Auf bekannte Änderungen in bestimmten Versionen kann man aber mit bedingter Kompillierung reagieren.

Dafür müsste man ja aber erstmal wissen, ob er noch funktioniert.

[Sir Rufo]

Wenn die Quellen vorhanden sind dann würde ich dort eine protected property auf das Feld erstellen. Dann geht es wieder und der Eingriff bleibt auch kontrollierbar

[relocate]

Die Bearbeitung des Sourcecodes möchte ich vermeiden.

Und zwar, weil die ursprüngliche Unit in einer Delphiversion vorliegt und leicht abgewandelt (nicht durch mich, damit sie funktioniert) in einer Freepascalversion. Die abgeleitete Version soll nun für beide Versionen gelten, ohne eben in den Quellcode der Delphi bzw. Freepascalversion "rumzupfuschen" und damit ggf. andere es nutzen können ohne das zu müssen.

Ich habe hier noch eine Option getestet und werde noch eine weitere testen in der Hoffnung einigermaßen "sauber" zu arbeiten.

Gruß relocate und danke für die Antworten

PS.: Könnte jemand probieren ob diese Art Hacks in späteren Delphiversionen (D7 und später) überhaupt funktionieren?!

[stahli]

Ich kann mich dem Wunsch absolut anschließen.

Ich wollte unter VCL und FMX schon einige Bugs beseitigen oder Funktionalitäten ändern, dann waren aber private Felder nicht zugänglich oder Methoden nicht virtuell.

Auf private Felder könnte man ja heutzutage notfalls über die RTTI zugreifen aber sinnvoll ist das sicher nicht.
Nett wäre eine Möglichkeit, dass man die Sichtbarkeit privater Felder in Ableitungen erhöhen könnte (wie man auch öffentliche Propertys später veröffentlicht). Das Feld ist ja da. Der Compiler muss ja den Zugriff lediglich erlauben.

Methoden sollten m.E. standardmäßig virtuell erzeugt werden (wenn man nicht "no virtual" deklariert). In den meisten Fällen denkt man beim basteln doch einfach nicht daran, "virtual" hinter die Deklaration zu schreiben (sofern man nicht selbst noch Ableitungen plant.)
Ob der Compiler nicht nachträglich noch Möglichkeit hätte, eine normale Methode überschreibbar zu machen, bzw. dies zu emulieren, vermag ich nicht zu beurteilen.
Evtl. wäre eine Deklaration "default override" ja realisierbar, wodurch der Programmierer den gleichen Zweck erfüllen könnte, intern das ganze aber anders realisiert wird.


Im Detail will ich mich da nicht zu weit aus dem Fenster lehnen, das Problem sehe ich aber auch als ein solches an.