Fragen zu OOP und Klassen: published, protected, ...

[Gonzo2]

@Phoenix

Ich hab ein wenig mit deiner Klasse experimentiert. Du hast Recht, es ist so, daß die private Variable in der Nachfolgeklasse nicht angesprochen werden kann, die protected schon. Allerdings gilt das nicht wenn man die Nachfolgeklasse in der gleichen Unit ableitet. Dann kann man auch auf die Variablen in private zugreifen. Böse Falle. Vor allem für Anfänger die dann kein Unterschied sehen. Also kann man für jeden Anfänger der üben will die goldene Regel geben:

Beim üben von Klassen, immer mit zwei Units arbeiten und den Nachfahren immer in einer zweiten extra Unit ableiten, sonst sieht man in der gleichen Unit Elemente die man eigentlich nicht sehen sollte.

Delphi-Quellcode:

//==== Unit1 ====
type
  TMyClass = class
  private
    fCreated: TDateTime; //mal private, mal protected
  protected
    //fCreated: TDateTime; //mal private, mal protected
  public
    constructor Create();
  end;

constructor TMyClass.Create();
begin
  fCreated := now;
end;

Delphi-Quellcode:

//==== Unit2 ====
type
  TMyClass2 = class(TMyClass)
  public
    constructor Create();
  end;

constructor TMyClass2.Create();
begin
  inherited;

  //fCreated := now-1; //versuchen Wert zu ändern, mal mit private, mal protected
end;

Bei einer Unit kann man bei der zweiten Klasse immer auf die Variable zugreifen, bei zwei Units klappt das nur bei protected.

Zitat von Luckie:

Hm, also ich dachte, das wäre in meinem Tutorial deutlich geworden.

Ja, es ist sonderbar, aber wenn man es verstanden hat, dann ergibt Deine Beschreibung wirklich Sinn. Vorher ist aber nicht klar wie das genau gemeint ist. Für den Wissenden ist das alles logisch, für den Unwissenden etwas unklar.

Zitat von Muetze1:

Nein, nicht explizit. Es kann published oder auch public sein!

Zitat von Delphi Hilfe:

Ein Element ohne Attribut erhält automatisch die Sichtbarkeit des vorhergehenden Elements in der Deklaration. Die Elemente am Anfang einer Klassendeklaration ohne explizite Sichtbarkeitsangabe werden standardmäßig als published deklariert, wenn die Klasse im Status {$M+} compiliert oder von einer mit {$M+} compilierten Klasse abgeleitet wurde. Andernfalls erhalten sie das Attribut public.

Acha, das ist die Erklärung. Es ist public, aber mit {$M+} ist es published.

Irgendwo habe ich gelesen, daß man selbst selten den Status {$M+} setzten muß, da in der Regel schon der Vorfahr den {$M+} Status gesetzt hat und damit wären Elemente ohne Sichtbarkeitsattribute published.


Abschließend will ich nochmal kurz auf public und published eingehen und ihre Wechselwirkung mit Komponenten. Das mit der Komponente testen ist etwas schwieriger, da hier dann erst die Komponente installiert werden muß usw. Werde ich noch machen, ist aber ein etwas größerer Aufwand.

Aber kann man das jetzt so sagen, daß der einzige Unterschied ist, daß public im OI nicht sichtbar ist und published schon. Ist das der einzige Unterschied? Oder gibt es da noch etwas mehr?

[Tyrael Y.]

Zitat von Gonzo2:

Aber kann man das jetzt so sagen, daß der einzige Unterschied ist, daß public im OI nicht sichtbar ist und published schon. Ist das der einzige Unterschied? Oder gibt es da noch etwas mehr?

Nicht ganz, nur published Elemente beinhalten RTTI-Informationen udn können aus diesem Grund auch im OI angezeigt werden.
Die RTTI-Informationen kann man aber auch selber nutzen, um in einem Objekt die vorhandenen Felder durchzugehen.

-> published und public unterscheiden sich dadurch, daß published RTTI-Informationen enthält, public nicht

[Gonzo2]

Also gut, noch weiß ich nicht 100% was RTTI ist, bis auf, daß es Laufzeit-Typinformationen sind, aber soweit kann ich vorerst damit leben. Bei published werden eben einige Informationen mitgeliefert die der OI braucht, bei public nicht.

Kann man somit sagen, daß published mit der Sicht auf Komponenten da ist? Oder nur für den OI?

Wie auch immer, gilt immer noch die Aussage, daß der OI keine public Eigenschaften zeigt, sondern nur published?

[Tyrael Y.]

Zitat von Gonzo2:

Kann man somit sagen, daß published mit der Sicht auf Komponenten da ist? Oder nur für den OI?

Wie auch immer, gilt immer noch die Aussage, daß der OI keine public Eigenschaften zeigt, sondern nur published?

Der OI kann nur published Eigenschaften zeigen, da es nur diese aus den RTTI-Informationen extrahieren kann. Man hat keine Möglichkiet durch public Eigenschaften einer Klasse zu iterieren und diese wie auch immer zu verarbeiten.

Erst durch das published sind Informationen in der Klasse vorhanden.


Man kann sich das so vorstellen, daß durch das published diese Felder in eine Art Liste landen und somit auch aus dieser Liste abgerufen werden können, alles was nicht published ist, ist auch nicht in der Liste und kann daher auch nicht abgerufen werden.

Das published ist also nicht nur für den OI da, sondern um Feldinformationen abfragen zu können, wer diese Informationen abfragt ist egal, es steht jedem zur Verfügung.

[taaktaak]

Moin, Moin!
Da möchte ich mal einhaken; Phoenix schreibt

Zitat:

Private
Nur sichtbar in der eigenen Klasse (und, aber das finde ich persönlich unschön, in anderen Klassen in der gleichen unit).
Eine abgeleitete Klasse kann auf ein private - Element nicht zugreifen.

Das habe ich vor einigen Tagen bei TSplitter schmerzlich erfahren. Ich benötige einen Splitter, in dem ich nicht nur den MinWert, sondern auch den MaxWert setzen kann. Dieser Wert existiert als FMaxSize - und ist als private deklariert.

Ich wusste mir nicht anders zu helfen, und habe den gesamten Quelltxte in eine "neue" Komponente kopiert und eben das gewünschte Verhalten "eingebaut" - aber ehrlich, das hat ja nun mit Vererben überhaupt nix zu tun. Die "eigene" Komponente in die Original-Unit zu packen erscheint mir irgendwie auch zweifelhaft.

Gibt es da wirklich keinen anderen Weg?????
Gruß Ralph

[Tyrael Y.]

Zitat von taaktaak:

Moin, Moin!
Gibt es da wirklich keinen anderen Weg?????

Leider nicht

...deshalb gehen viele Komponentenentwickler dazu über möglichst alle Felder als protected zu deklarieren und wirklich nur Felder, von denen man absolut annehmen kann, daß die von keinem Nachfolger mehr gebraucht werden könnten private zu machen

...ich mach das meist auch jetzt so, daß ich meistens Felder als protected deklariere

[Gonzo2]

Zuerst mal danke an alle. Meine Fragen sind zu den Punkten soweit geklärt.

Aber eine komische Kleinigkeit ist mir aufgefallen die eigentlich nicht sein sollte.

Hier eine Klasse und eine in einer exta Unit abgeleitete Klasse

Delphi-Quellcode:

//==== UNIT1 ====
type
  TMyClass = class
  protected
    fCreated: TDateTime;
    //function getCreated: TDateTime; //mal protected, mal public
  public
    constructor Create();
    function getCreated: TDateTime; //mal protected, mal public
  end;

  constructor TMyClass.Create();
  begin
    fCreated := now;
  end;

  function TMyClass.getCreated: TDateTime;
  begin
    result := fCreated;
  end;

Delphi-Quellcode:

//==== UNIT2 ====
type
  TMyClass3 = class(TMyClass)
  public
    constructor Create();
  end;

constructor TMyClass3.Create();
begin
  inherited;
  fCreated := now;
end; 

procedure TForm1.Button3Click(Sender: TObject);
var
  MyClass3: TMyClass3;
begin
  MyClass3 := TMyClass3.Create;
  try
    ShowMessage(DateToStr(MyClass3.getCreated));
    ShowMessage(DateToStr(MyClass3.fCreated));
  except
    MyClass3.Free;
  end;
end;

fCreated ist in TMyClass in protected, somit unsichtbar für Nutzung. Das stimmt auch soweit die Funktion getCreated in public ist. Verschiebe ich getCreated aber in protected, bietet meine abgeleitete TMyClass3 plötzlich auch fCreated an. Wie kann das sein? Ist doch protected.

[Tyrael Y.]

Du hast TForm und TMyClass3 in derselben Unit, deshalb klappt das auch.

Mach mal 2 verschiedene Units, eine für TMyClass, eine für TMyClass3, dabei aber TMyClass3 nicht wieder in dieselbe Unit wie die TForm packen, dann wird das nicht gehen.

[Gonzo2]

Über eine dritte Unit klappt das nicht.

Und wieso klappt das in Form1? Wird da alles zusammengeworfen?

Ist jetzt nicht so wichtig, interessiert mich nur so nebenbei.

[Gonzo2]

Nochmal kurz zu private, protected, public und published. Ich hab den Verwendungszweck mehr oder weniger verstanden. Allerdings hätte ich da noch eine Abschlußfrage, bzw. brauche ich eine Bestätigung.

Bei reinen Klassen kommen nur diese drei Schutzklassen zum Einsatz: private, protected und public. private wenn es privat sein soll und nur in der eigenen Klasse inc. der Unit sichtbar sein soll, später in abgeleiteten Klassen aber unsichtbar. protected wenn es privat sein soll und nur in der eigenen Klasse inc. der Unit sichtbar sein soll, später aber auch in abgeleiteten Klassen privat sichtbar bleiben soll. public wenn es öffentlich sein soll.

Soweit es ganz normale Klassen sind kommen nur diese drei Schutzklassen zum Einsatz. published spielt bei normalen klassen keine Rolle.

published, der ähnlich dem public ist, spielt erst dann eine Rolle wenn man Komponenten erstellt. Auf diese Weise kann man unter anderem steuern was im OI sichtbar sein soll.

Das ganze ist jetzt vereinfacht ausgedrückt, aber kann man das so in etwa sagen? Vor allem das mit published?