Feld nur über Property zugreifen

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