Benutzt ihr Properties?

[Gast]

Scania schrieb:

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

Da ziehe ich den Debugger vor, der immer anhält, wenn der Wert der Variablen geändert wird.

[Gregor]

dschensky schrieb:

Aber was ist an

auto.AnzahlRaeder = 4;

denn "irreführend"?

Es könnte zum Beispiel Nebeneffekte haben, die von der Syntax her IMHO nicht zu erwarten sind.

[Gregor]

fffffffff schrieb:

ich denke, dass eine zuweisung

Bla=10;

einfacher ist als

klasse.SetBla(10);

Siehste, du bist schon auf die Syntax hereingefallen, denn dein "Bla=10;" ist in Wirklichkeit keine Zuweisung.

[Shade Of Mine]

Gregor schrieb:

dschensky schrieb:

Aber was ist an

auto.AnzahlRaeder = 4;

denn "irreführend"?

Es könnte zum Beispiel Nebeneffekte haben, die von der Syntax her IMHO nicht zu erwarten sind.

Naja, ein setWheels() sollte auch keine Nebeneffekte haben - zumindest wuerde ich davon nicht erwarten, dass auf einmal die Fahrertuer aufgeht :p

Ich bin auch kein Freund von Properties - aber ich sehe da weder Vor- noch Nachteile.

Klar, Properties koennen Neulinge verwirren - aber das koennen alle Sprachfeatures.

Und die Kapselung brechen sie auch nicht - wie denn auch? Nur weil die Syntax eine andere ist?

Das einzige was ich doch etwas komisch finde ist, wenn man

foo.bar=3;
machen kann, aber bei einem
print(foo.bar);
einen Fehler bekommt.

Allerdings habe ich noch keine 'set-only' Verwendung gesehen.

Trotzdem bevorzuge ich getter/setter - allerdings ohne besonderen Grund (einfach Geschmackssache).

Was ist denn nun aber genau der Nachteil an Properties? Durch ihre Einfuehrung hat man nun statt jeder Zuweisung eine Funktion. Einzig, dass es ungewohnt ist - dass man Member aendert und dann keine Update Funktion oder aehnliches aufrufen muss

[net 0]

da ist ja wieder das problem (siehe size_t/hungarian thread). properties muss man irgendwie kennzeichnen (z.b. indem sie komplett gross geschrieben werden) um sie von normalen variablen zu unterscheiden.

btw: aber da gibt's ja noch ganz andere verwirrtechniken in c# z.b. das 'readonly' keyword

[Gregor]

Shade Of Mine schrieb:

Naja, ein setWheels() sollte auch keine Nebeneffekte haben - zumindest wuerde ich davon nicht erwarten, dass auf einmal die Fahrertuer aufgeht :p

Das Objekt könnte zum Beispiel eine Variable "Reifenzustand" haben, die als Nebeneffekt verändert wird.

Aber nimm mal ein anderes Beispiel. Wie wäre es mit einer Klasse für komplexe Zahlen, die die Properties Real, Imaginary, Argument und Norm hat. Du wirst hier Nebeneffekte haben, es ist also nicht nur ein theoretisches Problem. ...aus meiner Sicht ist es nunmal extrem verwirrend, wenn ein x.A = b. keine Zweisung ist. x.A muss hier ja nichtmal existieren.

BTW: Mit "impliziten Dingen" in Java bin ich auch nicht glücklich. Das neue Autoboxing gefällt mir z.B. überhaupt nicht.

[AndreasW]

Optimizer schrieb:

Das tust du mit den Proberties i.d.R. nicht, da sie oft wirklich nur auf eine Variable abgebildet werden.

ähm, es gibt im Hintergrund, also in der Verarbeitung von Properies, kein Unterschied zwischen einer "Geter-Setter-Methoden"- Lösung
Wenn man ein Fehler in einem Property verursacht, kann man im Debugger auch sehen, dass sich hinter dem Property zwei Methoden (sofern get und set drin sind) verbergen.

Properties verbergen genauso gut Variablen wie Methoden. Wenn jemand eine Variable einfach durchreichen oder setzen möchte, kann er dass auch in der Methoden-Variante machen.

Optimizer schrieb:

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.

Nutzlos keineswegs. Ich sehe Properies in einer Klasse auch als Eigenschaft an. Methoden sind halt irgendwelche Aktionen in der Klasse, welche ausgeführt werden können. Eine derartige Differenzierung macht durchaus Sinn und hat auch viele Vorteile.
Siehe auch Datenbindung.

Optimizer schrieb:

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.

Ich bin froh, dass es drin ist.

[AndreasW]

Gregor schrieb:

dschensky schrieb:

Aber was ist an

auto.AnzahlRaeder = 4;

denn "irreführend"?

Es könnte zum Beispiel Nebeneffekte haben, die von der Syntax her IMHO nicht zu erwarten sind.

ja, aber hat das nicht eher was mit schlechten Klassendesign zu tun als mit den Properties selbst ?

Also lass uns da nicht vom Thema abweichen

[Gregor]

AndreasW schrieb:

ja, aber hat das nicht eher was mit schlechten Klassendesign zu tun als mit den Properties selbst ?

Ne, das hat nichts mit schlechtem Klassendesign zu tun. Solche Nebeneffekte können sich während der Entwicklung einer Klasse ganz automatisch ergeben, wenn sich zum Beispiel die konkrete Implementation durch ein Refactoring ändert.

[AndreasW]

Beispiel die konkrete Implementation durch ein Refactoring ändert.

ok, nenne mir ein Beispiel eines Nebeneffektes. Erkläre dabei welche Rolle dabei das Property selbst spielt, und wie du das mit der Methoden-Variante verhinderst.

[Gregor]

AndreasW schrieb:

ok, nenne mir ein Beispiel eines Nebeneffektes. Erkläre dabei welche Rolle dabei das Property selbst spielt, und wie du das mit der Methoden-Variante verhinderst.

Ich habe oben bereits ein Beispiel einer Klasse angegeben, die nicht ohne Nebeneffekte programmiert werden kann. Das Problem sind aber nicht die Nebeneffekte ansich, sondern der Eindruck der Zuweisung, der bei der gegebenen Syntax der Properties entsteht. Man hat nicht mehr den Eindruck, dass eine Methode aufgerufen wird, was ich für schlecht halte. Bei Methoden weiß ich, dass sich darin vieles verbergen kann. Wenn ich ein "=" sehe, dann denke ich, dass das eine Zuweisung ist, bei der sonst nichts passiert.

[h4xX0r]

Das musst du aber nur denken, wenn es in deinen Klassen public-Variablen gibt, was auf einen Designfehler deuten würde, weil man nie Properties und Publicvars mischen sollte.

[AndreasW]

ähm,

sorry, ich kan nkein Beispiel von dir finden. Viellicht bin ich ja auch mal wieder blind.

Findest du deine letzte Antwort nicht ein wenig subjektiv ?

Properties sind Methoden, dass halten wir doch mal fest. Properties dann generell eine Schuld an Nebeneffekten zu geben halte ich für ziemlich wage. Schließlich spielt die Implementierung der Geter und Setter-Teile genau so eine rolle wie bei der Methoden-Variante.

Man hat nicht mehr den Eindruck, dass eine Methode aufgerufen wird, was ich für schlecht halte.

Wozu brauch ich gedanklich eine Methode wenn ich eine Eigenschaft meine.

wo bitte liegt der Unterschied:

public class Auto
{
 private bool _Fernicht;
 private bool _Abblendlicht;
 public bool Fernlicht
 {
   get{return _Fernlicht;}
   set
   {
     if(value && !_Abblendlicht)
        _Abblendlicht= true;
     _Fernlicht=value;
   }   
 }

  public SetFernlicht(bool AValue)
 {
     if(AValue && !_Abblendlicht)
        _Abblendlicht= true;
     _Fernlicht=value;
 }
}

wo bitte ist da der Unterschied ? Warum sollte da ein Propery zu Nebeneffekten führen und SetFernlicht nicht ?

Warum soll SetFernlicht(true) gedanklich schlüssiger sein als Fernlicht=true; ?

ist das vielleicht doch nur eine alte, vielleicht überholte, Gewohnheitssache ?

[Gregor]

h4xX0r schrieb:

Das musst du aber nur denken, wenn es in deinen Klassen public-Variablen gibt, was auf einen Designfehler deuten würde, weil man nie Properties und Publicvars mischen sollte.

Du solltest am Besten ganz schnell damit aufhören, blind irgendwelchen "Richtlinien" oder so zu folgen. Wenn einer sagt, dass man Membervariablen kapseln sollte, dann solltest du die Allgemeinheit dieser Aussage hinterfragen. Man macht das ja nicht zum Selbstzweck und es gibt durchaus Stellen, an denen das nicht angebracht ist.

[h4xX0r]

Mich kann man leicht überzeugen. Wo ist es denn nicht angebracht ? Wo sind public Variablen besser als Properties ?

[Gregor]

AndreasW schrieb:

sorry, ich kan nkein Beispiel von dir finden. Viellicht bin ich ja auch mal wieder blind.

Findest du deine letzte Antwort nicht ein wenig subjektiv ?

1. Ich meinte generell eine Klasse für komplexe Zahlen.

2. Natürlich sind alle meine Aussagen subjektiv. Ich bin nur ein Mensch. Bezogen auf diese Sache kann ich nur sagen, dass ich kein Computer und auch keine IDE bin, die mit solchen Dingen keinerlei Probleme haben. Für mich hat der optische Eindruck eines Codes durchaus Bedeutung. Keine Ahnung, ob andere Leute das anders sehen. Ich denke aber, dass sie sich etwas vormachen würden, wenn sie das Gegenteil behaupten.

[Talla]

Das Properties nur eine einzelne Variable darstellen ist glaub ich nur in einfachen Szenarien der Fall, meist steckt dahinter wirklich nen bisschen mehr Programmlogik als nur ne einfache Zuweisung, aber was soll schlimm daran sein das es aussieht wie eine Zuweisung? In Setter Methode übergibt man doch auch den Wert und in Getter Methoden bekommt man nen Rückgabewert, ist doch bei Properties genau das gleiche.

@h4xX0r
Du hast nen kleinen Fehler in deiner sig, ich würd mich über 160 MB Festplattenkapazität nicht grad freuen

@AndreasW
Es macht halt kein Unterschied, nur dein kleines Beispielprogramm hat nen Fehler weil die Anfangszustände nicht klar sind. Wenn nämlich Ablendlicht auf false ist und du setzt Fernlicht auf true, ist bei dir danach beides an. Kann passieren im eifer des Gefechts

[Gregor]

h4xX0r schrieb:

Mich kann man leicht überzeugen. Wo ist es denn nicht angebracht ? Wo sind public Variablen besser als Properties ?

Pfff... guck dir eine beliebige Bibliothek an. Da findest du genug öffentliche Membervariablen, obwohl andererseits auch viele Variablen gekapselt sind. Es gibt durchaus Stellen, an denen man vorher weiß, dass eine Kapselung nur einen unnötigen Overhead mit sich bringt.

[Gregor]

Talla schrieb:

Das Properties nur eine einzelne Variable darstellen ist glaub ich nur in einfachen Szenarien der Fall, meist steckt dahinter wirklich nen bisschen mehr Programmlogik als nur ne einfache Zuweisung, aber was soll schlimm daran sein das es aussieht wie eine Zuweisung? In Setter Methode übergibt man doch auch den Wert und in Getter Methoden bekommt man nen Rückgabewert, ist doch bei Properties genau das gleiche.

Ok, ich habe schon ein paarmal gesagt, wo ich einen Unterschied sehe (Ich halte die Syntax für schlecht, weil sie eine Zuweisung suggeriert). Soll ich es noch ein paarmal sagen? ...und es ist natürlich nicht genau das Gleiche wie bei Gettern und Settern. Im Gegenteil: In der Syntax liegt der einzige Unterschied.

Einige finden die Syntax toll, weil sie weniger tippen müssen, ich finde sie halt doof, weil sie irreführend ist.

[Gast]

Gibt es Proberties auch bei structs? Wenn nicht, hat sich das Thema zumindest für Complex schon mal erledigt, weil eine Klasse, die vermutlich aus nur 2 Membern besteht, würde ich sicher nicht als class implementieren.
So etwas gehört auf den Stack.