Compiler Anweisung strict protected

[ATS3788]

Hallo Freunde des großen Delphi

Ich bin bei dem Ribbon Interface von Bilsen
auf die
Compiler Anweisung strict protected
gestoßen. Was ist denn das schon wider.
Protected ist klar aber das "Strict".
Was ist der Unterschied ?

[mkinzler]

Das dies auch innerhalb einer Unit gilt.

[Stevie]

Normalerweise sind private und protected innerhalb derselben Unit nicht gültig. D.h. du kannst von außerhalb dieser Klasse auch auf die Member zugreifen. Der Zusatz strict setzt diese Sichtbarkeit auch innerhalb derselben Unit durch, was zu weniger verwobenem Code führen kann. Die Auswirkungen merkt man meist erst, wenn man mal 2 so verzahnte Klassen (beide greifen gegenseitig auf private und protected Member zu) in ihre eigenen Units verschieben möchte.

Kleiner Wermutstropfen, solltest du selber die Benutzung in Betracht ziehen - die Codevervollständigung kommt auch Jahre nach Einführung dieser keywords nicht so toll damit zurande.

[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 ...