Feld nur über Property zugreifen

[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 von DeddyH:

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 von 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.

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.