Frage zu Propertys

[ByTheTime]

Hallo,
wenn ich eine Klasse schreibe und eine Property lesen und schreiben möchte, dann schreibe ich mir für das Schreiben immer einen "Setter", wie es hier beschrieben ist. Das habe ich schon immer so gemacht.

Aber was spricht denn gegen property Name: String read FName write FName; ?
Ich schreibe ja auch nicht für jede Property einen "Getter"...

Gruß,
Lukas

[Dejan Vu]

Eigentlich gar nichts.

[ByTheTime]

Hmmm... Dann werde ich das in Zukunft so machen

[Lemmy]

ist mehr zu schreiben als

property Name: String; und anschließend Shift+SRTG+C

[Dejan Vu]

Und mehr überflüssiger Code.

[Sir Rufo]

Zitat von Lemmy:

ist mehr zu schreiben als

property Name: String; und anschließend Shift+SRTG+C

stimmt propf und TAB und den Namen

[Dejan Vu]

Wo war jetzt nochmal im Eingangspost die Bemerkung, das die Anzahl der Tastendrücke irgendeine Rolle spielt?

[himitsu]

Wenn im Setter absolut nichts gemacht wird, außer in das Feld zu schreiben, dann ist der natürlich sinnlos und du kannst direkt in das Feld schreiben.
Vom Code her ist es dennoch möglich später einen Setter einzufügen, wenn dieser nun doch benötigt wird.

Der Vorteil beim Setter ist, daß du dort einen Haltepunkt reinmachen kannst, um Schreibzugriffe zu debuggen.
Oder man kann dort den zugewiesenen Wert prüfen und ungültige Werte unterbinden.
Aber, wie bereits erwähnt, dannst du den nötigen Setter dann immernoch einbauen.

Zitat von Sir Rufo:

stimmt propf und TAB und den Namen

propf[space]Bar[enter]string[enter]

http://www.delphipraxis.net/179343-k...ml#post1250033
http://www.delphipraxis.net/180540-e...ml#post1260501
...

PS: Diese Vorlagen erzeugen sogar das Feld FName: string; , wenn es noch nicht existiert.



[add]
http://www.delphi-treff.de/object-pa...n-und-objekte/

Das Tutorial sollte man besser mal reparieren.

Zitat:

Destructor Free;

Free?
Und wo ist das Override?
Und wo sind die Inherited?
Und weiter wollte ich nicht mehr schauen, da ich Angst bekommen hab.

[alda]

Wenn ich noch etwas hinzufügen darf:
Properties mit direkten Lese- und/oder Schreibzugriff auf Variablen sind meines Erachtens unsauber und "starr" (natürlich gibt es wirklich Ausnahmen, bei denen es sich für uns Delphi-Entwickler vielleicht wirklich nicht lohnt extra Getter/Setter anzulegen). Aber letztendlich entspricht das der Veröffentlichung einer Variable (also "public FVariable: Integer" (Lesen + Schreiben)) und ist auch in anderen Sprachen eher ein NoGo würde ich sagen.

Es macht meines Erachtens in den meisten Fällen durchaus Sinn sich die "Mühe" zu machen Getter und Setter zu schreiben, da man so viel flexibler ist. Außerhalb deiner Klasse hat es niemanden zu interessieren was Du intern machst (z.B. den Wert in die entsprechende Variable zu schreiben). Mit Flexibel meine ich: Du musst deine Property-Deklaration nicht anpassen wenn Du die interne Variable änderst (read/write Sektion) und Du kannst problemlos weitere Aktionen innerhalb der Getter und Setter antriggern, die im Laufe der Entwicklung vielleicht noch kommen (nach dem Setzen z.B. Log schreiben, vor dem Lesen ein Flag setzen oder sonst was).

Ich finde es am elegantesten gleich mit Interfaces zu arbeiten, wo Du dann auch gezwungen wärst ()Getter und Setter zu implementieren. Hier hast Du dann in den Tests auch den Vorteil, deine Klassen einfacher zu mocken (durch Testklassen auszutauschen).

[mkinzler]

Zitat:

Properties mit direkten Lese- und/oder Schreibzugriff auf Variablen sind meines Erachtens unsauber und "starr" (natürlich gibt es wirklich Ausnahmen, bei denen es sich für uns Delphi-Entwickler vielleicht wirklich nicht lohnt extra Getter/Setter anzulegen). Aber letztendlich entspricht das der Veröffentlichung einer Variable (also "public FVariable: Integer" (Lesen + Schreiben)) und ist auch in anderen Sprachen eher ein NoGo würde ich sagen.

Würde ich nicht so sehen. Denn eine Property abstrahiert den Zugriff auf die eigentliche private Variable.

Zitat:

Es macht meines Erachtens in den meisten Fällen durchaus Sinn sich die "Mühe" zu machen Getter und Setter zu schreiben, da man so viel flexibler ist. Außerhalb deiner Klasse hat es niemanden zu interessieren was Du intern machst (z.B. den Wert in die entsprechende Variable zu schreiben).

Wie gesagt eine Property abstrahiert.

Zitat:

Mit Flexibel meine ich: Du musst deine Property-Deklaration nicht anpassen wenn Du die interne Variable änderst (read/write Sektion) und Du kannst problemlos weitere Aktionen innerhalb der Getter und Setter antriggern, die im Laufe der Entwicklung vielleicht noch kommen (nach dem Setzen z.B. Log schreiben, vor dem Lesen ein Flag setzen oder sonst was).

Wenn sich der interne Typ ändert, kannst Du dann auch das read/write auf einen Getter/Setter setzen. Warum sollte man gezwungen werden Methoden zu implementieren, welche nichts machen?