Compiler Anweisung strict protected

[klgid]

Wie ich gerade vor Kurzem lernen musste, sind 'private' und 'protected' nur für die Sichtbarkeit (also sozusagen Vorschläge)
und können in abgeleiteten Objekten geändert werden.
"strict" sorgt dafür, dass sie funktionieren, wie man es aus anderen Sprachen kennt ...

[DeddyH]

Das stimmt so nicht ganz. Private-Member sind nur innerhalb der eigenen Klasse sichtbar, Protected-Member auch in abgeleiteten Klassen. Delphi hat diese Sichtbarkeiten aber aufgeweicht: stehen 2 Klassen innerhalb derselben Unit, so haben sie auch Zugriff auf private und protected Member der jeweils anderen Klasse, was dem Prinzip der Kapselung widerspricht. Probleme gibt es daher dann, wenn man diesen Umstand zunächst ausgenutzt, später die Klassen aber aus Gründen der Übersichtlichkeit auf verschiedene Units aufgeteilt hat. Daher wurde das "strict" eingeführt, was die Sichtbarkeiten im Sinne der Kapselung durchsetzt, so dass Klassen keinen Zugriff auf strict private und strict protected (es sei denn, es ist eine abgeleitete Klasse) mehr erhalten.

[klgid]

Genau das dachte ich auch.

Ich ging auch davon aus, dass das auch für abgeleitete Objekte gilt.
Leider musste ich mich in einer HandsOn-Experience auf unserem letzten DelpHHianer-Meeting eines besseren belehren lassen:

Klasse ClassA hat ein private Feld FFieldA.
Klasse ClassB wird - in einer gesonderten Unit - von ClassA abgeleitet und definiert FFieldA erneut, diesmal als public.
Damit greifen wir nunmehr public auf FFieldA von ClassA zu ...

Ich habe den Code selbst getippt, es stimmt wirklich.
Wenn ClassA allerdings FFieldA als STRICT private deklariert, funktioniert das nicht mehr.

Ach ja:
Helper Classes haben auch direkten Zugriff auf alles ...

[himitsu]

Zitat von klgid:

von ClassA abgeleitet und definiert FFieldA erneut

Feld = "Variable"?

Nein, dann wird die Sichtbarkeit nicht geändert, sondern zu hast zwei Felder, die zufällig gleich heißen.

[Sir Rufo]

Hier habe ich das mal erklärt
http://stackoverflow.com/questions/1...58763#16558763

[himitsu]

Und das Andere auch noch als Beispiel:

Delphi-Quellcode:

type
  TKlasseA = class
    FFeld: Integer;
  end;
  TKlasseB = class(TKlasseA)
    FFeld: Integer;
    constructor Create;
  end;

constructor TKlasseB.Create;
begin
  FFeld := 123;
  inherited FFeld := 456;
  ShowMessage(Format('%d %d', [FFeld, inherited FFeld]))
end;

Aber da aus unerfindlichen Gründen inherited nicht bei Feldern funktioniert, noch schnell ein Property oder Getter/Setter dazwischen.

Delphi-Quellcode:

type
  TKlasseA = class
    FFeld: Integer;
    property Feld: Integer read FFeld write FFeld;
  end;
  TKlasseB = class(TKlasseA)
    FFeld: Integer;
    property Feld: Integer read FFeld write FFeld;
    constructor Create;
  end;

constructor TKlasseB.Create;
begin
  Feld := 123;
  inherited Feld := 456;
  ShowMessage(Format('%d %d', [Feld, inherited Feld]))
end;

Und nun noch schnell aufrufen.
TKlasseB.Create.Free; Aber da man Felder sowieso niemals öffentlich deklarieren sollte, sondern nur Private und in sonderfällen maximal Protected, ist das egal, denn die Sichbarkeit der Property, für den Zugriff darauf, kann man ja verschieben.

[klgid]

Dachte ich auch - und wurde enttäuscht
Ich habe das wirklich auf Diktat codiert und musste feststellen, dass Delphi (XE7) sich hier anders verhält als erwartet.
Wir (DelHHianer) nehmen an, dass dies ursprünglich so gedacht war, und später "strict" eingeführt wurde, um das erwartete Verhalten (wie bei Java u.a.) zu ermöglichen.

Ehrlich:
Ich wollte es auch nicht glauben!
Musste mich aber eines (Besseren?) Anderen belehren lassen.

Langer Rede, kurzer Sinn:
1. Wenn Ihr Eure Objektfelder privat halten wollt, verwendet STRICT PRIVATE!
2. Prüft noch einmal, worauf abgeleitete Objekte und Helfer Klassen zugreifen können ...

Inzwischen hat Sir Rufo auf einen Beitrag verwiesen.
Kurz überflogen stimmt der mit meiner ursprünglichen Sicht überein.

Versucht bitte einfach einmal, mein unten beschriebenes Szenario nachzuvollziehen - es funktioniert (leider)

[Der schöne Günther]

Ich verstehe das "leider" immer noch nicht.

private und protected heißt: "(Unterklassen und )selbe Unit"
Mit "strict" heißt es: "(Unterklassen)"

Und ein Klassenhelfer fühlt sich an keine Sichtbarkeitsmodifikatoren gebunden. Was ist denn daran jetzt so abenteuerlich?

[mkinzler]

Ohne strict it alles innerhalb der selben Unit public. Die Sichtbarkeit wirkt sich nur über Unitgrenzen aus. Mit strict erzwingt man das auch innerhalb der Unit.

[klgid]

Zitat von Der schöne Günther:

Ich verstehe das "leider" immer noch nicht.

private und protected heißt: "(Unterklassen und )selbe Unit"
Mit "strict" heißt es: "(Unterklassen)"

Und ein Klassenhelfer fühlt sich an keine Sichtbarkeitsmodifikatoren gebunden. Was ist denn daran jetzt so abenteuerlich?

Abenteuerlich ist daran, dass ich eine Berechnungsklasse schreibe und meine Berechnungsgrundlagen als PRIVATE markiere, damit mir niemand meine Berechnungen verändern kann, PRIVATE aber leider nicht UNVERÄNDERBAR bedeutet. STRICT PRIVATE tut dies dann ...

Diese Diskussion ist natürlich zu 99.9% philosophisch, d.h. es geht darum, inwieweit sich Delphi an anderen Sprachen orientiert.
"private" in JAVA ist PRIVATE, "private" in Delphi ist ...

Ich poste nachher noch entsprechenden Source - aktuell läuft auf meinem System gerade ein Update ...