Benutzt ihr Properties?

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

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