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

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

[Der schöne Günther]

Zitat von klgid:

Helper Classes haben auch direkten Zugriff auf alles ...

Dass Helferklassen auch auf private Attribute zugreifen können ist beabsichtigt. Ist anderswo zwar anders, aber ob das nun besser oder schlechter ist?