Delphi - Eigenschaften

[himitsu]

Jupp, von der Definition her ist es erstmal rech einfach zu verstehen:

private kann nur die Klasse selber, also auch keine Nachfahren
protected kann nur die Klasse und ihre Nachfahren
public können Alle
und published ist wie public mit Zusatzinfos für das Streaming, also da können auch auch fremde Klassen über die TypeInfo (RTTI) drauf zugreifen.


published: siehe Unit TypInfo sowie TObject.MethodAddress, TObject.MethodName und TObject.FieldAddress.
Für Klassen ab TPersistent/TComponent ist die Standatd-Sichtbarkeit von public auf published geändert > siehe {$TYPEINFO} / {$M+}
Diese Funktionen werden z.B. für das Streaming der DFM verwendet.

Und dann noch der Sonderfall innerhalb der eigenen Unit.
Innerhalb einer Unit ist ALLES dort Deklarierte wie public, also auch fremde Prozeduren und Klassen dürfen auf alles zugreifen.
Darum wurde inzwischen das strict eingeführt, also strict private und strict protected sind nur dort so, wie es die Grunddefinion für private und protected besagt.

[Ghostwalker]

Zusätzlich zu dem oben genannten, kannst du den Zugriff auf Properties genauer steuern, da du Funktionen/Prozeduren für das Lesen und Schreiben einer Property hinterlegen kannst.

Beispiel:

Delphi-Quellcode:

Type
  TTest = Class
  private
     fname : string;
  protected
    Procedure SetName(const value:string);
    function GetName:string;
  public
  published
    Property Name: string read GetName write SetName;
  end;

Implementation
   
   Procedure TTest.SetName(const value:string);
   begin
     if (copy(value,1,2) = 'XX') then
       fname := value;
   end;

   function TTest.GetName:string;
   begin
    result := copy(fname,3);
   end;

In dem Beispiel wird der Wert von Property Name nur gesetzt, wenn der zu setzende Wert mit 'XX' anfängt.
Beim lesenden Zugriff werden die ersten beiden Zeichen weggelassen.

Zugegeben ist das Beispiel nicht sehr sinnvoll, aber sollte die vorgehensweise demonstrieren.

Sinnvolle Anwendungen gibts haufenweise (Prüfungen beim Setzten, Abhängigkeiten verschiedener Properites untereinander....).

[Der schöne Günther]

Was Delphi allerdings fehlt ist der Komfortmechanismus dass die Property z.B. nur von protected beschrieben und von public gelesen werden kann, auch wenn die get.. und set..-Methoden eigentlich schon genau das sagen.

Auch aus dem Grund dass andere Sprachen ganz hervorragend ohne Properties und nur get.. und set..-Methoden auskommen hab ich persönlich nie gesehen was man durch Properties nun gewonnen hat. Außer noch mehr tippen zu dürfen.

[Ghostwalker]

Zitat von Der schöne Günther:

Was Delphi allerdings fehlt ist der Komfortmechanismus dass die Property z.B. nur von protected beschrieben und von public gelesen werden kann, auch wenn die get.. und set..-Methoden eigentlich schon genau das sagen.

Delphi-Quellcode:

  TTest = Class
  private
     fvalue : string;
  protected
     Procedure SetValue(const value:string);
  public
     property Value : String read fvalue write SetValue;

Sowas ?

Zitat von Der schöne Günther:

Auch aus dem Grund dass andere Sprachen ganz hervorragend ohne Properties und nur get.. und set..-Methoden auskommen hab ich persönlich nie gesehen was man durch Properties nun gewonnen hat. Außer noch mehr tippen zu dürfen.

Was hindert dich daran, das in Delphi genauso zu machen ?

Delphi-Quellcode:

   TTest = Class
   private
     fvalue : string;
   public
     function GetValue:string;
     procedure SetValue(const str : String);

[Der schöne Günther]

Zitat von Ghostwalker:

Sowas ?

Ja, das meine ich: Die Property mit ihrem read und write ist public , es darf also jeder dran. Egal wie welchen Zugriff die Methoden oder Felder dahinter haben.

Zitat von Ghostwalker:

Was hindert dich daran, das in Delphi genauso zu machen ?

Nichts. Deswegen tue ich es auch. Ich wollte nur mein Unverständnis ausdrücken was man durch Properties in seinem Code überhaupt gewinnt.

[mkinzler]

Zitat:

Ich wollte nur mein Unverständnis ausdrücken was man durch Properties in seinem Code überhaupt gewinnt.

Der Grund für die Erfindung von Properties heisst Objektinspektor.

[Der schöne Günther]

Dass Delphi seit den 90ern seine DFM-Dateien über published Properties serialisiert ist mir klar. Ich sehe nur nicht weshalb man das heute in eigenem Code einsetzen sollte.

[Ghostwalker]

Zitat von Der schöne Günther:

Zitat von Ghostwalker:

Sowas ?

Ja, das meine ich: Die Property mit ihrem read und write ist public , es darf also jeder dran. Egal wie welchen Zugriff die Methoden oder Felder dahinter haben.

Das ist doch nur eine Frage in welchem Abschnitt ich die Property definiere. Wenn ich nicht möchte, das jemand von "außen" auf die Property zugreifen soll, dann leg ich die Property in einen entsprechenden Abschnitt oder
definier einfach das entsprechende Feld im Abschnitt und mach keine Property draus.

Mit Hilfe der Getter/Setter kann ich, obwohl die Property von "außen" sichtbar ist, den Zugriff auf den Inhalt der Property kontrollieren.

Aber irgendwie hab ich so das Gefühl, das ich nicht so ganz verstehe, worauf du rauswillst

[Der schöne Günther]

Zitat von Ghostwalker:

Mit Hilfe der Getter/Setter kann ich, obwohl die Property von "außen" sichtbar ist, den Zugriff auf den Inhalt der Property kontrollieren.

Nein, das kannst du eben nicht: "Zugriff kontrollieren". Die Property kann nicht zwischen "Lesezugriff" und "Schreibzugriff" unterscheiden. Entweder man hat vollen Zugriff auf die Property (dann ist es herzlich egal ob die Getter/Setter nun private, protected oder public sind), oder keinen.

Ich finde es ist ein legitimer Anwendungsfall dass z.B. die Klasse selbst eine Property schreiben, ein Benutzer der Klasse ("von außen") die Property aber nur lesen kann.


Das heißt eine Property kann im Endeffekt sogar weniger als zwei Getter/Setter-Methoden und ist sogar mehr Tipparbeit.

[himitsu]

Zitat von Der schöne Günther:

Auch aus dem Grund dass andere Sprachen ganz hervorragend ohne Properties und nur get.. und set..-Methoden auskommen hab ich persönlich nie gesehen was man durch Properties nun gewonnen hat. Außer noch mehr tippen zu dürfen.

Die Getter und Setter kannst du dir schon ewig automatisch generieren lassen.

> Templates/Live-Templates : propxyz und dann nur noch Name und Typ eingeben > fertig

Zitat von Der schöne Günther:

Was Delphi allerdings fehlt ist der Komfortmechanismus dass die Property z.B. nur von protected beschrieben und von public gelesen werden kann, auch wenn die get.. und set..-Methoden eigentlich schon genau das sagen.

Aber dann müsste ich ja alle Getter und Setter gleich public/published machen, weil man (leider) nur die Sichtbarkeit von Properties nachträglich ändern/erhöhen kann. (den Sonderfall mit Override ignoriere ich jetzt mal)

Delphi-Quellcode:

type
  // mit normaler Vererbung geht es nicht, auch wenn der Setter eigentlich nur Protected ist, wird er in A2 zusammen mit dem Property nach Public mitgenommen
  TMyClassA = class
  strict protected
    function MyGetter: Integer;
    procedure MySetter(Value: Integer);
  strict protected
    property MyProp: Integer read MyGetter write MySetter;
  end;
  TMyClassA2 = class(TMyClassA)
  public
    property MyProp read MyGetter;
  end;

  // Sichtbarkeiten zurückzunehmen geht, auch wenn man sowas eigentlich niemals nie nicht machen würde :)
  TMyClassB = class
  strict protected
    function MyGetter: Integer;
    procedure MySetter(Value: Integer);
  public
    property MyProp: Integer read MyGetter;
  end;
  TMyClassB2 = class(TMyClassB)
  strict protected
    property MyProp write MySetter; // eigentlich müsste der Compiler hier meckern, weil das bösartig gegen die Vererbungsrichtlinien verstößt (vielleicht meckert er grade nicht, weil alles in der selben Unit liegt und das strict noch recht jung und unausgereift ist)
  end;

  // aber niemand verbietet dir sowas ;)
  TMyClassX = class
  strict private
    function MyGetter: Integer;
    procedure MySetter(Value: Integer);
  strict protected
    property MyPropS: Integer read MyGetter write MySetter;
  public
    property MyProp: Integer read MyGetter;
  end;

procedure TForm6.FormCreate(Sender: TObject);
var
  A: TMyClassA2;
  B: TMyClassB2;
begin
  if A.MyProp = 123 then ;
  A.MyProp := 123;

  if B.MyProp = 666 then ;
  B.MyProp := 666;  // [DCC Fehler] E2129 Einer Nur-Lesen Eigenschaft kann kein Wert zugewiesen werden
end;