Feld nur über Property zugreifen

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