Nachfahr-Klasse sieht private-Member der Vorfahrklasse?

[Codehunter]

Hallo!

Mir ist schon vor einiger Zeit aufgefallen, dass in Delphi (sowohl 5 als auch 7) Nachfahren manchmal, also nicht immer, einige private-Member der Vorfahrklasse sehen können. Ein Beispiel:

Delphi-Quellcode:

type
  TBaseClass = class
  private
    FMember: Integer;
  end;

  TDescendantClass = class(TBaseClass)
  public 
    procedure DoSomething;
  end;

implementation

procedure TDescendantClass.DoSomething;
begin
  FMember:= 123; // <-- Hier müsste es krachen, tuts aber nicht
end;

Ist das normal? Ich hab nie absichtlich so programmiert, ist mir nur immer dann aufgefallen wenn Nachfahren sich seltsam verhielten weil ich eigentlich vergessen hatte eine Member im Nachfahren zu erstellen, der Compiler sich aber nicht darüber aufregte. Stattdessen gab es unvorhersehbare Ergebnisse.

Also mir widerspricht das den Sichtbarkeitsregeln. Oder denke ich falsch?

Grüße
Cody

[mkinzler]

Ja, alle Klassen in der selben Unit sehen das. Um das zuverhindern muss man strict private verwenden

[Neutral General]

Innerhalb einer Unit ist das bei Delphi so.
Keine Ahnung warum.

Aber es gibt auch "strict private". Das bewirkt dann das, was man von "private" erwartet.

[Daniel]

Menno. Das wollte ich auch schreiben.

[Uwe Raabe]

Zitat von Daniel:

Menno. Das wollte ich auch schreiben.

Da weiß man mal was, und dann...

[Codehunter]

Was ist "strict private"? Ich kenne das nicht, gibts das schon in D5 und D7? In der Hilfe find ich auch nix dazu.

[mkinzler]

Das wurde erst später eingeführt, um eine bessere Kompatibilität mit dem Verhalten zu anderen Sprachen zu erhalten. Wenn ich mich richtig ersinne mit D10 (D2006)

[Luckie]

Aber normalerweise sollte man auch nur eine Klasse in eine Unit machen, weil das dann eine logische und physische Einheit ist. Also ich mache es immer so.

[negaH]

ich sehe überhaupt kein Problem in diesem Verhalten. Die Deklaration zweier Klassen im gleichen Gültigkeitsbereich (hier Interface Sektion einer Unit) bestimmt die Sichtbarkeit aller Variablen, Konstanten, OOP Konstrukte. Möchte man dies nicht so muß man die Klassen in eigene Units auslagern. Es ist aber eher so, das wenn der Programmierer sich dafür entschieden hat zwei Klassen in der gleichen Unit zu deklarieren, das diese beiden Klassen zusammengehörig sind. Man möchte explizit das in den Blackboxen, sprich Mehtoden der Objekte, Zugriff auch auf die privaten Felder der kompletten Klassenhierarchie, die man vorherig deklariert hat, möglich ist.

Es ist also nur eine Frage des Verständinisses beim Programmierer und seinen Designzielen. Vom Verständniss her sollte klar sein das diese Kapselung/Sichtbarkeiten nicht nur für OOP gilt sondern für alle Sprachfeature von PASCAL. Könnte man eine Klasse ganz privat innerhalb einer Methode/Procedure deklarieren dann wäre das die Fortsetzung des Sichtbarkeitskonzeptes wie es jetzt schon existiert. Dies Sichtbarkeitsebenen sind "Program/Library" -> "Unit" -> "Interfacesection/Implementationsection der Unit" -> "Klassen/Methoden/Procedure Deklaration" -> "Methoden/Procedure-Implementation" -> "nested Functions" -> "begin end" -> "Unterblöcke wie if then begin end; Schleifen usw."

Es ergibt sich also eine modulare Hierarchie, sowohl als Dateistruktur wie auch innerhalb dieser Quelltexte als Syntax der Programiersprache, die gerade bei PASCAL ziemlich strikt hierarisch ist und an Hand derer auch die Sichtbarkeiten und damit Kapselung definiert ist. Anders ausgedrückt: ich liebe PASCAL weil auch die "graphische" Orientierung dessen was man im Quelltext schreibt ein wichtige Funktion hat. PASCAL besteht nicht nur aus einer Syntax sondern auch aus "Formatierungs-Regeln" die uns die Struktur des gesammten Quelltextes viel besser vestehen lässt.

Mit der späteren Einführung von "strict private" hat man das als Sprachfeature umgesetzt um noch gezielter die Sichtbarkeiten, und damit Fehlervermeidung, beeinflussen zu können.

Beides halte ich für sinnvolle Instrumente.

Gruß Hagen

[himitsu]

*zustimm*

Gut, andere mögen es auch schön finden, daß man Header und Implementation in C nochmals in getrennten Dateien ablegt (*.h und *.c), aber am Ende dafür alle Header sich in einem großen Mischmasch vereinen.


PS: Es gibt auch strict protected, mit den selben Einschränkungen ... nur bei public und published hat man es sich erspart (wäre ja auch vollkommen sinnlos gewesen)