Feld nur über Property zugreifen

[Kostas]

Hallo Zusammen,

ist es möglich ein Feld innerhalb der Klasse zu sperren so dass man nur über das Property darauf zugreifen kann?

Delphi-Quellcode:

unit Tester;

interface

uses Winapi.Windows;

type
 TTest = class
  private
    fID : Integer;
    function GetID:Integer;
    procedure SetID(value: integer);
    procedure doWork;
  public
    property ID:Integer read GetID write SetID;
  end;


implementation

{ TTest }

procedure TTest.doWork;
begin
  fID := -10;  //<<< Wie kann den Zugriff auf das Feld innerhalb der
              //     Klasse verhindern so dass ich über das Property gehen muss.
  ID := -10;

end;

function TTest.GetID: Integer;
begin
  result := fID;
end;

procedure TTest.SetID(value: integer);
begin
  if value < 0
  then fID := 0
  else fID := value;
end;

end.

[DeddyH]

Ich wüsste nicht, wie das gehen sollte. Da ist halt die Selbstdisziplin des Programmierers gefragt.

[Uwe Raabe]

Die Anforderung erscheint mir irgendwie unsinnig. Wenn es einen Weg gäbe, das Feld für jeglichen Schreibzugriff innerhalb der Klasse zu sperren, dann würde das ja auch für den Code in der Implementation von SetID gelten.

Man könnte das Feld aber auch mitsamt property und Zugriffsmethoden in eine Parent-Klasse verlagern und dort als strict private deklarieren. Dann kann man es in der Child-Klasse nicht mehr direkt ansprechen.

Delphi-Quellcode:

type
 TTestBase = class
  strict private
    fID : Integer;
    function GetID:Integer;
    procedure SetID(value: integer);
  public
    property ID:Integer read GetID write SetID;
  end;

type
 TTest = class(TTestBase)
    procedure doWork;
  end;

[dummzeuch]

Ich sehe da nur eine Möglichkeit, nämlich zwei Klassen statt einer:

Die erste Klasse enthält das Feld, die Property samt Zugriffsmethoden (evtl. virtual). Dabei wird das Feld als strict private deklariert, der Rest als public oder protected, je nachdem welche Sichtbarkeit gewünscht ist.

Die zweite ist von der ersten abgeleitet und enthält alles andere. Methoden dieser zweiten Klasse können nicht auf das Feld zugreifen, weil es als strict private deklariert ist.

Edit: Uwe war schneller.

[bcvs]

Ich würde vielleicht sowas machen:

Delphi-Quellcode:

type
 TTest = class
  private
    fMyStrictprivateIDWithSecretName : Integer;
    function GetID:Integer;
    procedure SetID(value: integer);
    procedure doWork;
  public
    property ID:Integer read GetID write SetID;
  end;


implementation

{ TTest }

function TTest.GetID: Integer;
begin
  result := fMyStrictprivateIDWithSecretName;
end;

procedure TTest.SetID(value: integer);
begin
  if value < 0
  then fMyStrictprivateIDWithSecretName := 0
  else fMyStrictprivateIDWithSecretName := value;
end;

Und im weiteren Verlauf dann vergessen, dass es dieses fMyStrictprivateIDWithSecretName gibt. Erhöht die angesprochene Selbstdiszpilin.

[Uwe Raabe]

Alternativer Vorschlag ohne Vererbung:

Delphi-Quellcode:

type
  TSafeInteger = record
  strict private
    FValue: Integer;
  public
    class operator Implicit(A: TSafeInteger): Integer; overload;
    class operator Implicit(A: Integer): TSafeInteger; overload;
  end;

class operator TSafeInteger.Implicit(A: TSafeInteger): Integer;
begin
  Result := A.FValue;
end;

class operator TSafeInteger.Implicit(A: Integer): TSafeInteger;
begin
  if A < 0 then
    Result.FValue := 0
  else
    Result.FValue := A;
end;

type
  TTest = class
  strict private
    fID: TSafeInteger;
    function GetID: Integer;
    procedure SetID(value: integer);
  private
    procedure doWork;
  public
    property ID:Integer read GetID write SetID;
  end;

procedure TTest.doWork;
begin
  fID := -10;  // hier wird intern eine 0 geschrieben!

//  aber das geht halt nicht:
//  fID.FValue := -10; 
end;

function TTest.GetID: Integer;
begin
  result := fID;
end;

procedure TTest.SetID(value: integer);
begin
  fID := value;
end;

[Kostas]

Hallo Zusammen,

die Absicht ist, mich selbst vor Fehlern zu schützen. :-) Dieses Beispiel passt relativ gut zu meinem Fall. Ich hatte vergessen dass ich für das Feld ein property erstellt hatte, der die Gültigkeit der Werte über einen Getter schützt. Wenn ich nicht daran denke, und das Feld direkt anspreche, umgehe ich die Getter Methode. Wenn es keine Möglichkeit gibt das Feld zu Schützen, werde ich solche Felder zukünftig besonders benennen nach dem Muster:

Code:

fUseProperty_Depp_ID : Integer;

mit der Hoffnung dass ich dann beim Anwender darauf stoße und nach einem Property schaue. Ich hatte gehofft, es gibt so etwas wie eine Section "private protected" und ich muss nur das Feld in dieser Section verschieben und fertig.

[DeddyH]

Lustig, so ähnlich sieht mein Code für meinen eigenen Nullable Type auch aus :-). Trotzdem stellt sich mir hier die Frage nach der Sinnhaftigkeit, irgendwie widerspricht das doch den Grundsätzen der OOP, eine Klasse hat immer Zugriff auf ihre eigenen Felder.

[Uwe Raabe]

Zitat:

Zitat von DeddyH (Beitrag 1537102)

eine Klasse hat immer Zugriff auf ihre eigenen Felder.

Das hat sie ja. Der Idee ist eben, die Wirkung eines Zugriffs zu kontrollieren. In diesem Fall ist das die Begrenzung auf einen Mindestwert bei Zuweisung. Dafür wird eben ein eigener Typ verwendet.

Das ist in der Tat ganz ähnlich wie bei Nullable-Types. Da wird ein vorhandener Datentyp auch um eine bestimmte Funktionalität ergänzt.

[joachimd]

Dann nimm doch immer einen richtigen Namen, über den Du zugreifst. Falls dann ein Property daraus wird, ist die Eigenschaft mit dem vorangestellten 'f'. Die nimmst du eben nie, nie, nie in Deinem Code - ausser im Setter/Getter.
Das sollte die Leichtsinnsfehler vermeiden helfen.

[Kostas]

Ich verwende Propertys IMMER wenn ich von außen auf public Member einer Klasse zugreife.
Innerhalb der Klasse gemischt. Ich sehe einfach den Sinn nicht dass ich für eine Feld immer ein Property erstellen soll wenn es Anforderung an der Kontrolle gibt. Die Variante mit dem Class Operator finde ich sehr Sinnvoll. So wie es aussieht könnte man damit dem direkten Zugriff auf die Felder einen Rigel vorschieben.

[joachimd]

Zitat:

Zitat von Kostas (Beitrag 1537109)

Ich verwende Propertys IMMER wenn ich von außen auf public Member einer Klasse zugreife.
Innerhalb der Klasse gemischt. Ich sehe einfach den Sinn nicht dass ich für eine Feld immer ein Property erstellen soll wenn es Anforderung an der Kontrolle gibt. Die Variante mit dem Class Operator finde ich sehr Sinnvoll. So wie es aussieht könnte man damit dem direkten Zugriff auf die Felder einen Rigel vorschieben.

Es geht um den Namen....Wenn Du ein mentales Problem damit hast, das Feld statt das Property zu verwenden, dann gewöhne Dich an eine gute Namensgebung, also zB niemals auf ein Feld zugreifen, welches mit f beginnt. Wenn Du trotzem kein Property daraus machen willst, dann lass das f weg. Sollte es doch mal ein Property werden, wird das Feld umbekannt und ein Property eingeführt, welches den bisherigen Namen bekommt.

[Kostas]

ist bestimmt eine gute Idee. Leider haut mir niemand auf die Finger wenn ich mich an meine eigene Regeln nicht halte weil ich gerade in Gedanken bin und einfach nicht daran gedacht habe. Ich müsste es mindestens Idiotensicher für mich machen indem ich das Feld so benenne dass ich auch darüber stolpern würde Like "fUseProperty_ID: integer" normalerweise sollte ich beim schreiben des Feldbezeichners Wach werden. Die Methode vom Uwe mit dem Class Operator zwingt mich allerdings dazu und ich kann es nicht umgehen. Allerdings ist das mit deutlich mehr Arbeit verbunden. Wenn ich jedoch beim Umsetzen daran gedacht habe ein Class Operator zu erstellen dann ist dieses Feld für immer sicher.

Wenn es eine Section geben würde und ich NUR das Feld in dieser Section verschieben müsste wäre das echt cool. Aber anscheinend braucht das niemand.

[Uwe Raabe]

Zitat:

Zitat von Kostas (Beitrag 1537111)

Wenn es eine Section geben würde und ich NUR das Feld in dieser Section verschieben müsste wäre das echt cool. Aber anscheinend braucht das niemand.

Wie schon erwähnt: Wie soll der Compiler denn erkennen, in welchen Methoden er das Feld verwenden darf und in welchen nicht? Was zeichnet einen Setter aus, dass die Einschränkung dort nicht gilt? Es kann zwar eine Bindung eines Properties an ein Feld geben aber nicht umgekehrt.

Wenn es wirklich gar nicht beschrieben werden soll, dann kann man es auch per

Delphi-Quellcode:

const

erreichen, aber das ist ja gar nicht was du willst.

[Kostas]

ich habe schon verstanden dass das nicht geht.

Ich dachte wirklich an so etwas:

Delphi-Quellcode:

type
 TTest = class
  private
    function GetID:Integer;
    procedure SetID(value: integer);
    procedure doWork;

  private protected  //<< Wenn es so eine Section geben würde, könnte man das so interpretieren dass dessen Member nur über ein property zu erreichen sind. 
    fID : Integer;

  public
    property ID:Integer read GetID write SetID;
  end;

Wie gesagt, ich habe schon kapiert dass es eben nicht geht und mit deinem Vorschlag der Class Operator gibt es ja auch eine Lösung.
Soweit ich mir erinnern kann, ist es bei C# so dass man auf die Felder nie direkt zugreifen kann. Hier muss man immer über Properties gehen. Das hat mich an C# allerdings auch gestört weil einfach mehr Arbeit. :-)

[Frickler]

Wenn Du Setter und Getter hast, gib dem Feld halt eben nicht den Namen "Property mit vorangestelltem 'f'", sondern etwas extrem auffälliges, etwa mit dem Zufallsgenerator generiert, wie das Obfuskator-Programme mit Quellcode machen.

Code:

procedure TMeineKlasse.SetID(Value: integer);
begin
  __b4rea2toynks := Value;
end;

[Blup]

Ich denke das Problem ist eher ein Symptom dafür, dass die Klasse zu viele Verantwortlichkeiten hat.
Daten und Funktionalität zu trennen ist ein erster wichtiger Schritt.
Datenobjekte sollen nur die Datenstruktur abbilden aber keine fachliche Funktionalität enthalten.
Die gehört ins Model und das kann ebenfalls aus mehreren Unterklassen bestehn, die sich um einzelne Aufgaben kümmern.

Im Prinzip kann man jeden Anwendungsfall ähnlich aufbauen.
Dann findet man sich auch leichter zurecht, wenn mehrere Entwickler am selben Projekt arbeiten z.B.:

Code:

Model.Data             .. Datenobjekt das alle Daten modeliert, mit denen gearbeitet wird (Unterobjekte, Listen)
Model.Repository       .. Klasse zum Lesen und Speichern der Datenobjekten
Model.Config           .. Enthält alle Einstellungen die mit Hilfe des Repository geladen oder gespeichert werden
Model.Provider         .. stellt Schnittstellen zu anderen Anwendungsfällen bereit (z.B. Erlöskonten, Steuerarten ..), die Klasse wird dem Model beim Erzeugen mitgegeben
Model.Provider.Config .. falls die Einstellungen aus globalen Quellen stammen und nicht vom Model selbst geladen werden
Model.Params           .. falls die Parameter nicht direkt an die Funktionen des Models übergeben werden, wird vom Model in der Schnittstelle veröffentlicht

So hat das Model nur noch Variablen für den aktullen Status und die braucht man nur vor dem Zugriff über die Schnittstelle zu schützen (readonly).

Man kann andere Strukturen für die Anwendung wählen, aber ohne Struktur werden große Anwendungen schnell unübersichtlich und kaum noch wartbar.

[freimatz]

Zitat:

Zitat von joachimd (Beitrag 1537110)

Zitat:

Zitat von Kostas (Beitrag 1537109)

Ich verwende Propertys IMMER wenn ich von außen auf public Member einer Klasse zugreife.
Innerhalb der Klasse gemischt. Ich sehe einfach den Sinn nicht dass ich für eine Feld immer ein Property erstellen soll wenn es Anforderung an der Kontrolle gibt. Die Variante mit dem Class Operator finde ich sehr Sinnvoll. So wie es aussieht könnte man damit dem direkten Zugriff auf die Felder einen Rigel vorschieben.

Es geht um den Namen....Wenn Du ein mentales Problem damit hast, das Feld statt das Property zu verwenden, dann gewöhne Dich an eine gute Namensgebung, also zB niemals auf ein Feld zugreifen, welches mit f beginnt. Wenn Du trotzem kein Property daraus machen willst, dann lass das f weg. Sollte es doch mal ein Property werden, wird das Feld umbekannt und ein Property eingeführt, welches den bisherigen Namen bekommt.

Bei uns haben Felder für Properties eine andere Namensgebung als Felder ohne Properties. Und das ist bei uns Pflicht. Wenn man sich einmal daran gewöhnt hat, die Felder für Properties nur in bestimmten Situationen zu verwenden dann klappt das recht gut.