property oder variable

[khh]

hallo zusammen,
welchen Vorteil bewirkt die Deklaration einer property mit eigenen Zugriffsmethoden ala:

Delphi-Quellcode:

interface
  TSimpleStringList = class
  private
    FList: array of string;
  protected
    function Get(Index: Integer): string;
    procedure Put(Index: Integer; const S: string);
  public
    property Strings[Index: Integer]: string read Get write Put; default;
  end;

im Gegensatz dazu das Array public zu deklarieren

Delphi-Quellcode:

public
  List: array of string;

die Zugriffsmethoden auf das "normale" Array sind ja eh schon implementiert.



Danke für eure Meinungen

Gruss KH

[Sharky]

Naja,

in einer Setter oder Getter Methode kannst Du ja zum Beispiel noch plausibilitätsprüfungen durchführen.

[khh]

Zitat:

Zitat von Sharky

Naja,

in einer Setter oder Getter Methode kannst Du ja zum Beispiel noch plausibilitätsprüfungen durchführen.

ok

das ist ein Argument.

[himitsu]

Und du kannst vorallem später mal leicht etwas ändern.

Also am Besten niemals Felder direkt freigeben, sondern immer über ein Property (selbst wenn da noch nichtmal Getter und Setter vorhanden sind).
Später kann man immernoch leicht eine Getter/Setter nachrüsten und so etwas verändern ... wie z.B. ein OnChange-Ereignis einrichten oder eben die schon genannten Plausibilitätsprüfungen.

Dieses ist ja gerade ein Vorteil von OOP, gegenüber "einfachen" Records.
(die neuen Recordmethoden überseh ich jetzt einfach mal)

[Medium]

Darüber hinaus ist dies schlicht näher am OOP Paradigma, dass u.a. das so genannte Geheimhaltungsprinzip postuliert, nach dem sämtliche inneren Zustände und Abläufe einer Klasse von aussen nicht greifbar sind, und lediglich über ein Interface indirekt zugänglich sein sollen. (Dies muss nicht zwangsweise wirklich über die Technik "Interface" passieren, die Terminologie überkreuzt sich da etwas. Properties bzw. Getter/Setter sind ein Interface im semantischen Sinne - also genau genommen vom Interface als eigene weitere Methodik in der OOP abzugrenzen.)

Diese Begründung läuft jedoch pur über eine theoretische Definition. Technisch kann ggf. ein Propertyzugriff nachher genau so vom Compiler realisiert sein wie ein direkter (wenn das Property direkt auf das Feld durchgreift ohne einen Getter/Setter zu deklarieren in diesem Falle). Es ist prinzipiell eine ganz gute Idee an diesem Paradigma festzuhalten, da es wie schon erwähnt insbesondere die Wartbarkeit deutlich verbessern kann. Lediglich in sehr sehr wenigen Fällen gibt es wirklich einen guten Grund für die Verwendung von Public-Feldern. Sehr selten.

[fLaSh11]

Vor allem kannst du auch mithilfe des Setters dem Benutzer deiner Komponente einiges an Arbeit abnehmen, indem du z.B. nach der schon genannten Plausibilitätsprüfung - es sei: Zugriffs-Index > High(FList) -, das Array automatisch vergrößerst.

Und beim Direktzugriff auf das Array muss der Benutzer auch Prozeduren wie z.B. Add, Insert, Delete selbst schreiben; das könntest du ja in deine Komponente einbauen. Sonst könntest du ja auch einfach nur die Liste ala Array of String in dein Programm übernehmen, da die Komponente ohne Benutzung der OOP-Methodik sinnlos ist :)

[guidok]

Ein weiterer Grund kann es sein, wenn du dem Benutzer der Klasse gar nicht alle Zugriffsmöglichkeiten auf ein Feld erlauben möchtest, die der Typ des Feldes schon hergibt, z.B. stellt TStringList die Methode delete bereit, was du dem Benutzer aber nicht erlauben willst.

[khh]

wunderbar, ich danke euch, ihr hab mich überzeugt .

Gruss KH