Gundsatzfrage: Zugriff auf Feld über Namen oder Property?

[Pilloker]

Hallo,

ich habe eine Klasse, die verschiedene Variablen besitzt, die ich im Private-Abschnitt deklariert habe.
Für den Zugriff von außen habe ich eine entsprechende Property mit Getter- und Setter-Methoden angelegt, bzw. automatisch durch Delphi anlegen lassen.

Meine Frage ist nun aber, wie man von 'innen' also von der Klasse selber aus auf diese Felder zugreift.
Macht man das generell über den Namen, also bspw. fBlabla oder generell auch über die Property, oder ist das von der jeweiligen Situation abhängig?

Gibt es diesbezüglich irgendein 'Regelwerk', an das man sich halten sollte?

Der Grund meiner Frage ist folgender:
Nehmen wir mal an, dass ich bisher in der Klasse ausschließlich über den Feldnamen direkt auf die Variable zugegriffen habe.
Nun merke ich, dass ich auf dieses Feld auch von außen zugreifen muss, und erstelle mir ein entsprechendes Property.
Ich überschreibe die automatisch generierte Setter-Methode, die ja per fBlabla := Value einfach direkt auf die Variable zugreift, und erweitere sie um ein paar Plausibilisierungen.

Damit ich nun auch bei Zugriffen von 'innen' von diesen Plausibilisierungen profitieren kann, müsste ich sämtliche Zugriffe, die jetzt noch direkt auf den Feldnamen gehen, durch die Property ersetzen.

Klar könnte man jetzt sagen, dass genau dieser Umstand doch ein eindeutiges Indiz dafür sei, dass man stets über die Property geht, und niemals direkt über den Feldnamen; auch nicht innerhalb der eigenen Klasse.

Ad hoc würde ich sagen, dass nur die Initialisierung mit Defaultwerten im Constructor per Direktzugriff auf das Feld geht und alles andere über Properties; auch von 'innen'.

Aber soll ich für jedes Feld eine Property anlegen, und dann darüber zugreifen, nur weil es sein könnte, dass ich irgendwann mal einen etwas umfangreicheren Getter/Setter benötige?
Und wo sollte ich die Properties dann deklarieren, um den Zugriff von außen (auch in Ableitungen) erstmal zu unterbinden? Im Private-Teil? Sieht doch irgendwie seltsam aus.
Auf der anderen Seite müsste ich die Sichtbarkeit dann nur noch auf protected/public erhöhen, wenn ich das Feld dann irgendwann doch mal von außen zugänglich machen möchte.

Hmm, irgendwie drehe ich mich im Kreis.

Wie handhabt Ihr das?

[hoika]

Hallo,

"Jeder Zugriff auf eine Variable erfolgt über ein property"

Punkt aus, setzen ! ;)

Ich habe früher nur Variablen benutzt,
bin dann aber auf den property-Geschmack gekommen.

Hauptsächlich des Debuggens wegen,
also um festzustellen, wann sich eine Variable ändert.

Und du hast Recht, im Constructor nehme ich die private-Variable.


Heiko

[DeddyH]

Aber nicht den Fehler machen und im Setter versehentlich auf die Property zugreifen (das ist mir mal passiert).

[Pilloker]

Danke erstmal für Eure Antworten.

Das mit dem Debuggen hat natürlich was; so spart man sich den umständlichen Weg über Adresshaltepunkte.

@Detlef: :mrgreen:

Noch eine Frage:
Ihr deklariert dann wirklich die Properties im Private-Abschnitt und erhöht dann entsprechend nur noch die Sichtbarkeit, wenn Ihr sie nach außen zugänglich haben möchtet?

[DeddyH]

Wenn es sich um eine Basisklasse handelt, packt man die Properties zweckmäßigerweise in den protected-Abschnitt. Die abgeleiteten Klassen können die Sichtbarkeit dann je nach Bedarf erhöhen (die VCL macht davon selbst regen Gebrauch, schau Dir nur mal die ganzen TCustom...-Klassen an). Eine private Property macht in meinen Augen lediglich in Verbindung mit einem Setter Sinn, sonst könnte man ja gleich direkt auf das Feld zugreifen.

[Pilloker]

Ja, das mit der Basisklasse und Protected ist mir schon klar.

Aber da liegt ja genau das Problem.

Hoika schreibt, dass jeglicher Zugriff ausschließlich über Properties gehen sollte, so wie es auch meine Vermutung war.
Um den Zugriff von außen dann erstmal zu unterbinden, muss ich die Property ja als private deklarieren und kann dann ggf. die Sichtbarkeit erhöhen.

Lasse ich die Property ganz weg habe ich irgendwann u.U. das Problem, alles von Feldname auf Property umzustellen, falls die Variable doch mal von außen zugänglich sein muss.

Ich möchte eine generelle und möglichst flexible Lösung.
Da erscheint mir das mit der Property im private-Abschnitt schon ganz nett.
Die Frage ist nur, ob das sauber ist.

[DeddyH]

Zitat:

Zitat von Pilloker

Um den Zugriff von außen dann erstmal zu unterbinden, muss ich die Property ja als private deklarieren und kann dann ggf. die Sichtbarkeit erhöhen.

Nur dass wir nicht aneinander vorbeireden: Du meinst, dass Du während des Entwicklungsprozesses der Klasse einen externen Zugriff unterbinden möchtest? Oder geht es um eine Klasse und deren Ableitungen?

[Pilloker]

Es geht erstmal um eine Klasse. Ob diese als Basisklasse dienen soll, oder nicht, ist erstmal irrelevant.
Alles kann, nichts muss :zwinker:

Daher möchte ich flexibel sein.

[DeddyH]

Gut, dann nochmal folgendes Beispiel:

Delphi-Quellcode:

type
  TMyClass = class
  private
    FFeld: integer;
    function GetFeld: integer;
    procedure SetFeld(const value: integer);
    property Feld: integer read GetFeld write SetFeld;
  protected
  public
  end;

Innerhalb der Implementation dieser Klasse greifst Du nur über die Property zu, richtig (außer im Getter/Setter)? Ich sehe jetzt spontan nichts, was dagegen spräche, gerade wenn der Setter noch eine Plausibilitätsprüfung enthalten sollte. Sollte sich später herausstellen, dass ein externer Zugriff sinnvoll ist, Cut&Paste auf die Property-Deklaration und Sichtbarkeit erhöhen... fertig. Ist doch ne prima Idee.

[edit] Editiert wegen fehlenden Syntax-Highlightings [/edit]

[Satty67]

Ihr greift auf private Felder auch innerhalb der Klasse immer via property zu? Ist das jetzt mehr "Geschmacksache" oder sinnvoll?

Wie sieht das mit Feldern aus, die Event-Methoden halten? Assigned("Getter") funktioniert ja nicht so richtig, wie man das in dem Fall erwarten würde...

[Pilloker]

@Detlef
Ja, genau so habe ich mir das vorgestellt. Das (außer im Getter/Setter) erweitere ich aber noch um den Constructor. Hier initialisiere ich die Varaiblen dann auch direkt mit Defaultwerten.

Ich habe die Properties schonmal in der Hinterhand und kann dann bei Bedarf die Sichtbarkeit erhöhen.

Und ich habe den von hoika genannten Vorteil beim Debuggen.

Edit:
@Satty - ich denke mal, dass die Getter-Methode in 99% der Fälle statisch ist, also sowieso direkt auf den Feldnamen geht. Mir geht es hauptsächlich um den Setter.

[DeddyH]

Eben, wenn der Wert der Property geändert wird, wird auch der Setter durchlaufen, sofern vorhanden. Deshalb sprach ich auch von Plausibilitätsprüfungen innerhalb desselben, denn eine Klasse kann sich ja auch selbst "verwursten", wenn man nicht aufpasst :mrgreen:

[Pilloker]

Blöd ist halt, dass man, ist das Feld ein Array, dessen Dimensionen mit SetLength nicht über die Property ändern kann :(

[Satty67]

Da müsste man dann Konsequent sein und über eine Property Count lösen? ;)

[Pilloker]

Man könnte die Property auch einer lokalen Variablen dieses Types zuweisen, diese dann erhöhen, und anschliueßend wieder zurück zuweisen:

Delphi-Quellcode:

   Var
      oBla: TMeinArray;
   Begin
      oBla := MeinArray;
      SetLength(oBla, Length(oBla) + 1);
      oBla[Length(oBla) - 1] := MeinArrayInhalt;
      MeinArray := oBla;