Benutzt ihr Properties?

[interpreter]

Siehte Threadtitel.
Einerseits finde ich sie ja ganz praktisch, aber als Java/C++ler dreht mir sowas eher den Magen um:
f.X = 2

Weil man auf den 1. Blick nicht sieht, ob hier einfach ein public Member geschrieben wird oder ein Property zum Einsatz kommt. Drum meine Frage: Benutzt ihr lieber klassische setter/Getter (getX() etc) oder Properties?

[Gast]

Ich benutze sie nicht. IMHO verletzen sie das Prinzip der Kapselung, da sie deutlich machen, dass es hier ein Datenelement gibt, was man verstellen kann.
Gut, man kann den Zugriff kontrollieren.
Aber ich bevorzuge dann eher sowas wie

auto.repariere() anstatt auto.damage = 0;

Bei sowas wie einem Form-Objekt ist es vielleicht nicht ganz unpraktisch. Aber dann hätte man sich darauf einigen sollen und nicht einerseits die Visible - Eigenschaft anzubieten, andererseit ne Methode Show() und Hide().

[interpreter]

hm, sehe ich eigentlich genauso. Ich denk, ich werd weiterhin bei meinen gettern/settern bleiben und Properties wirklich nur dann benutzen, wenn ich sonst public Fields nehmen würde (sprich: Nahezu nie )

[Noodles]

Ich nutze sie, denn ich kann in den Properties auch den Zugriff auf die Variable kontrollieren.

[AndreasW]

Properties benutz ich lieber, da man die mit DataBinding binden kann. Methoden nicht.

[h4xX0r]

Ich versuche die Variablen immer private oder protected zu halten. Wenn es nicht geht, dann kommt bei mir ne property zum Einsatz.

[dschensky]

Hallo,
Properties sind eine großartige Sache! Sie unterstützen das Kapselungs-Prinzip und es kommt sogar noch lesbarer Quellcode heraus. Da Properties auch virtuell oder statisch sein können, kann man damit so ziemlich alles anstellen.

Optimizer schrieb:

IMHO verletzen sie das Prinzip der Kapselung, da sie deutlich machen, dass es hier ein Datenelement gibt, was man verstellen kann.

Nun ja, das tut

auto.setAnzahlRaeder(4);

genauso und es ließe sich bei Verwendung einer Property wegen der angesprochenen Zugriffskontrolle aus

auto.AnzahlRaeder = 4;

eben nicht mit Sicherheit auf ein Datenelement (oder irgend etwas) schließen. (Ob das in diesem Fall sinnvoll währe, sei mal dahingestellt.)

Optimizer schrieb:

Aber ich bevorzuge dann eher sowas wie

auto.repariere() anstatt auto.damage = 0;

Da würde ich zustimmen. auto.repariere() ist viel aussagekräftiger und läßt vermuten, daß "Reparieren" ein u.U. komplexer Vorgang ist und nicht nur irgend eine Variable überschrieben wird. Die Frage, ob sich ein gegebenes Teilproblem in sinnvoller Weise als Property abstrahieren läßt, sollte natürlich immer gestellt werden. Ich halte es genauso für falsch, an alten Gewohnheiten festzuhalten und neue Sprachkonstrukture zu ignorieren, wie bewährte Techniken kommentarlos über Bord zu werfen.
Es lassen sich bestimmt auch etliche Beispiele finden, wo die Entscheidung Property/Methode letztlich "Geschmackssache" ist.

Optimizer schrieb:

Aber dann hätte man sich darauf einigen sollen und nicht einerseits die Visible - Eigenschaft anzubieten, andererseit ne Methode Show() und Hide().

Das ist auch Geschmackssache. Der eine bezeichnet das vielleicht als ein unnötiges Aufgeblasen der Schittstelle, ich finde das einfach nur ... praktisch.

[Gast]

Also die Kapselung unterstützen tun sie IMHO nicht. Kapselung heisst nicht, den Zugriff zu überwachen, sondern den Zugriff einzuschränken und Details zu verstecken. Das tust du mit den Proberties i.d.R. nicht, da sie oft wirklich nur auf eine Variable abgebildet werden.
Ich finde sie nicht generell nutzlos, so wie bei einer Form macht es schon Sinn. Vielleicht ist die Faustregel "statt public variable ein Proberty" nicht so schlecht.

Properties sind eine großartige Sache!

Aber IMHO mit Vorsicht zu genießen. Von allen neuen C# Features hätte ich auf jeden Fall auf dieses am ehesten verzichten können.

[c++eus]

Optimizer schrieb:

Also die Kapselung unterstützen tun sie IMHO nicht. Kapselung heisst nicht, den Zugriff zu überwachen, sondern den Zugriff einzuschränken und Details zu verstecken. Das tust du mit den Proberties i.d.R. nicht, da sie oft wirklich nur auf eine Variable abgebildet werden.

Hi,

die Frage von interpreter war, ob man Properties statt getter/setter benutzt. Du sagst nun, dass du lieber getter/setter benutzt, weil Properties nur die Variable abbilden. Das ist doch völlig unlogisch, weil getter/setter das ja auch machen.

Im übrigen würde niemand auto.damage = 0 statt auto.reparieren() schreiben, aber das war ja auch nicht die Frage von interpreter.

Properties machen das gleiche wie getter/setter, die Syntax ist aber IMHO schöner.

[Gregor]

c++eus schrieb:

Properties machen das gleiche wie getter/setter, die Syntax ist aber IMHO schöner.

IMHO ist die Syntax irreführend.

[c++eus]

Gregor schrieb:

c++eus schrieb:

Properties machen das gleiche wie getter/setter, die Syntax ist aber IMHO schöner.

IMHO ist die Syntax irreführend.

Und warum?

[Gregor]

c++eus schrieb:

Und warum?

Aus meiner Sicht erweckt sie den Eindruck einer Zuweisung, was sie nicht ist. Es kann sich etwas völlig anderes dahinter verstecken. Das "=" ist hier sozusagen ein wirklich schlecht überladener Operator. Genau wegen solchen Beispielen wird das Operator-Overloading von vielen Leuten abgelehnt.

[c++eus]

Gregor schrieb:

Aus meiner Sicht erweckt sie den Eindruck einer Zuweisung, was sie nicht ist. [...]

Aber das Präfix "set" in der Methode erweckt auch den Eindruck einer Zuweisung, oder etwa nicht? Und der Sinn der Properties ist es ja, den getter/settern eine "schönere" Syntax zu geben.

[Gregor]

c++eus schrieb:

Aber das Präfix "set" in der Methode erweckt auch den Eindruck einer Zuweisung, oder etwa nicht? Und der Sinn der Properties ist es ja, den getter/settern eine "schönere" Syntax zu geben.

Aus meiner Sicht wird bei der Verwendung von Gettern und Settern eindeutig klar, dass sich dahinter eine Methode verbirgt, die diverse Dinge beinhalten kann.

[fffffffff]

also, ich finde sie cool und praktisch und geil.
übrigens... ich komme aus auch der c++ welt.

dass sie gegen die kapselung verstossen iss doch absoluter schwachfug.

man kann sie ja auch private oder protected oder was weiss ich noch alles, machen.
oder eben gar nicht

ich denke, dass eine zuweisung

Bla=10;

einfacher ist als

klasse.SetBla(10);

und

if(Bla==10)

is sicher einfacher als

if(klasse.GetBla()==1=)

.............................

[Xqgene]

und was würde man ohne Properties machen in den modernen IDE's. man würde immer noch mit übertrieb Notepad programmieren. kein Designer, keine schöne Komponenten,...

[dschensky]

Hi,

Gregor schrieb:

IMHO ist die Syntax irreführend.

ich verstehe ja, daß etwa gelernte Java-Entwickler an ihren settern/gettern hängen.
(Ich komme eher aus der C++-Ecke, nörgele immer noch an den Interfaces herum und versuche instinktiv "drum herum" zu programmieren ...)
Aber was ist an

auto.AnzahlRaeder = 4;

denn "irreführend"?

[Xqgene]

ich würde wetten, dass danach auto.AnzahlRaeder == 5 ist !?

[Scania]

Eure Probleme möchte ich mal haben. Fact ist, dass mir Properties viele Möglichkeiten geben Anwendung (Komponenten) sicherer und stabiler zu machen und auch Designer-fähig zu machen.

Beispielweise nutze ich Properties im Debug-Modus als Private-Members um herauszufinden wer das jeweilige Feld verändert hat. Erleichert mir das Debuggen erheblich.

#if DEBUG
		private int _Test;
		private int Test 
		{
			get { return this._Test; }
			set { this._Test = value; }
		}
#else 
		private int Test;
#endif

[Gast]

fffffffff schrieb:

dass sie gegen die kapselung verstossen iss doch absoluter schwachfug.

man kann sie ja auch private oder protected oder was weiss ich noch alles, machen.
oder eben gar nicht

Du verstehst Kapselung nicht. Kapselung ist nicht, den Zugriff einzuschränken oder zu Überwachen, sondern zu abstrahieren und konkrete Details zu verbergen (!= gegen unbefugten Zugriff schützen), eine Schnittstelle unabhängig von der Implementierung zu ermöglichen.