Komponenten-Entwicklung: Interner Zugriff auf Eigenschaften

[APP]

Hallo,
ich bin auf eine "blöde" Frage gestossen:

Angenommen ich habe eine Komponente mit folgenden Eingenschaften:

Delphi-Quellcode:

  TFileBuffer = CLASS(TStringList)
  PRIVATE
    ...
    FItemSeperator: Char;
    FUNCTION GetObjectFileTime(Index: Integer): TDateTime;
    ...
  PUBLIC
     ...
    PROPERTY ObjectFileTime[Index: Integer]: TDateTime READ GetObjectFileTime WRITE SetObjectFileTime;
    PROPERTY ItemSeperator: Char READ FItemSeperator WRITE FItemSeperator;
    CONSTRUCTOR Create;
    DESTRUCTOR Destroy; OVERRIDE;
  END;

Nun steht im Handbuch (Seite 33-5 Delphi 5 deutsch) über die Eigenschaftsdaten,

• dass die zum Speichern verwendeten Felder als private deklariert sein müssen.
• dass aussschließlich die Implementierungsmethoden (Get_xxx und Set_xxx) auf diese Daten direkt zugreifen dürfen.
• dass wenn andere komponenteneigene Methoden/Eigenschaften auf Eigenschaftsdaten zugreifen wollen, dies ausschliesslich über die Eigenschaften und nicht direkt auf die Daten machen dürfen.

Mit anderen Worten:

Delphi-Quellcode:

{******************************************************************************}
FUNCTION TFileBuffer.GetObjectFileTime(Index: Integer): TDateTime;
{******************************************************************************}
// Nicht lauffähige DEMO-Methode!!
VAR
 aValue : Char;
BEGIN
...
// Wenn ich nun auf die Eigenschaft "ItemSeperator" zugreifen möchte
// müsste ich ja auf 
aValue := ItemSeperator;  //       ZUGRIFF ÜBER DIE EIGENSCHAFT
// und nicht auf 
aValue := FItemSeperator;  //      DIREKTER ZUGRIFF
// zugreifen?
END;

Es funktioniert offensichtlich beides, ausser wenn die Implementierung einer geerbten Eigenschaft geändert wird (lt. Handbuch).

Ich habe mir "renomierte" Projekte angesehen, und musste feststellen, jeder macht es anders (direkt, über die Eigenschaft oder gemischt), oder habe ich den tieferen Sinn nicht verstanden?

Meine Frage ist nun, ist das bloß eine Designfrage/Schwäche/Stilfrage, oder wie geht es nun "richtig"

[Sanchez]

schon des Designs wegen sollte man Variablen niemals public deklarieren.

[APP]

Hallo Sanches ,
meine Frage ist eigentlich, wie ich korrekt bei einer Komponente in einer Methode auf die Daten von (anderen) Eigenschaften zugreifen soll...

[Minz]

Ich glaube, dass ist blos ein Frage des schönen Stils.

Aber warum sollte man auch indirekt zugreifen, wenns auch direkt geht !

[Sanchez]

Zitat von APP:

meine Frage ist eigentlich, wie ich korrekt bei einer Komponente in einer Methode auf die Daten von (anderen) Eigenschaften zugreifen soll...

Ich glaube, ich verstehe die Frage nicht ganz.

Eine Methode einer Klasse kann doch ohne weiteres auf die Member-Variablen zugreifen. Wenn du in der Getter- bzw Setter-funktion irgendwelche Vorgänge drinnen hast, die du auch von der anderen Funktion aus benötigst, dann gehst du den Weg über die Property, ansonsten eben nicht.

[sakura]

Zitat von Minz:

Ich glaube, dass ist blos ein Frage des schönen Stils.

Stimmt.

Zitat von Minz:

Aber warum sollte man auch indirekt zugreifen, wenns auch direkt geht !

Es gibt gute Gründe über die Property zu gehen. Der wichtigste ist: man kann über die Methode GetXXX immer noch ein paar extra Tests machen (Plausibilitätstest), die bei direktem Zugriff auf die Variable nicht mit gemacht werden würden.

Ein hypothetische Frage

Was aber, wenn die property zum Lesen auch nur auf die Konstante zurückgreift.

Da würde ich gegenhalten, daß sich dieses mal ändern kann und man dann überall die Variable durch die Property auswechseln müsste.

Zum Punkt: Objektvariablen als private

Das ist lediglich eine Frage des sauberen Designs. Dadurch kann man sich selbst versichern, daß ein anderer Programmierer den Inhalt einer solchen Variable nicht direkt auf "legalem" Wege ändern kann, d.h. man kann durch die SetXXX Methoden immer die Oberhand wahren

Persönlich empfehle ich den direkten Zugriff auf die Variablen nur an drei Stellen: der GetXXX Methode, der SetXXX Mathode und die Methode (oft Create) welche zur Initialisieren (oder auch zum Reset) der Klasse/des Objektes genutzt wird.

......

[Minz]

@sakura

achso du meinst z.B. dies:

property MyVar: String read FMyVar write SetMyVar; und in SetMyVar machst du dann Plausibilitätstests?

[sakura]

Zitat von Minz:

und in SetMyVar machst du dann Plausibilitätstests?

Zum Beispiel. Wenn ich mit DCOM-Objekten arbeite, dann überprüfe ich in GetXXX zum Beispiel auch, ob diese noch existieren oder der Server u.U. abgeschaltet (oder BSoD) wurde, um dann dynamisch ein neues Objekt von einem anderen Server anzufordern.

Würde ich jetzt direkt auf die Variable zugreifen, könnte ich den Plausibilitätstest nicht mehr so einfach durchführen.

......

[APP]

Hallo Sakura,
vielen Dank für Deine Erklärungen, das war genau das wonach ich suchte!