C# 3.0-automatische Eigenschaften — hilfreich oder nicht?[geschlossen]

Question

Hinweis:Dies wurde geschrieben, als ich anfangen C#.Mit 2014 wissen, ich kann wirklich sagen, dass automatische Eigenschaften gehören zum besten, was je passiert ist und der C# - Sprache.

Ich bin verwendet, um meine Eigenschaften in C# mit einem privaten und einem öffentlichen Bereich:

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Nun, mit .NET 3.0, wir haben auto-Eigenschaften:

public string Title { get; set; }

Ich weiß, das ist mehr eine philosophische/subjektive Fragen, aber gibt es irgendeinen Grund, diese zu verwenden, auto-Eigenschaften, außer das speichern von fünf Zeilen von code für jedes Feld?Mein persönlicher Kritikpunkt ist, dass die Eigenschaften, die versteckt sind, die Sachen von mir, und ich bin nicht ein großer fan der schwarzen Magie.

In der Tat, die versteckten privaten Bereich gar nicht zeigen, bis in den debugger, was in Ordnung ist, angesichts der Tatsache, dass die get/set-Funktionen, die nichts zu tun.Aber wenn ich will, auch tatsächlich umzusetzen, einige getter - /setter-Logik, ich muss mit dem private - /public-pair-Mädchen sowieso.

Ich sehe den Vorteil, dass ich sparen eine Menge code (einer gegen sechs Zeilen), ohne die Fähigkeit zu ändern die getter - /setter-Logik später, aber dann wieder kann ich schon tun, indem Sie einfach erklären einem öffentlichen Feld "Public string Titel" ohne die Notwendigkeit der { get;set;} block, also noch mehr sparen code.

Also, was vermisse ich hier?Warum würde jemand tatsächlich verwenden möchten auto-Eigenschaften?

Answer 1

Wir benutzen Sie die ganze Zeit in Stack Overflow.

Sie könnten auch interessiert sein an eine Diskussion der Eigenschaften vs.Öffentliche Variablen.IMHO, das ist wirklich, was das ist, eine Reaktion auf, und für diesen Zweck, es ist großartig.

Answer 2

Ja, es tut nur speichern code.Es ist Meilen einfacher zu Lesen, wenn Sie haben eine Menge von Ihnen.Sie sind schneller zu schreiben und einfacher zu pflegen.Speichern von code ist immer ein gutes Ziel.

Sie können verschiedene Bereiche:

public string PropertyName { get; private set; }

So, dass die Eigenschaft kann nur geändert werden, innerhalb der Klasse.Dies ist nicht wirklich unveränderlich, wie Sie können immer noch Zugang zu den privaten setter durch Reflexion.

Ab C#6 können Sie auch wahr readonly Eigenschaften - d.h.unveränderliche Eigenschaften, die nicht geändert werden, außerhalb des Konstruktors:

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

Bei der Kompilierung werden:

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

Bei unveränderlichen Klassen mit viel Mitglieder das spart eine Menge überflüssigen code.

Answer 3

Die drei großen Nachteile der Verwendung Felder anstelle von Eigenschaften sind:

1. Sie können nicht databind auf ein Feld in der Erwägung, dass können Sie zu einer Eigenschaft
2. Wenn Sie beginnen mit einem Feld, kann später keine (leicht) ändern einer Eigenschaft
3. Es gibt einige Attribute, die Sie hinzufügen können, ist eine Eigenschaft, dass Sie können nicht hinzufügen, um ein Feld

Answer 4

Ich persönlich Liebe auto-Eigenschaften.Was ist falsch mit der Speicherung der Zeilen code?Wenn Sie möchten, um Dinge zu tun in Getter oder setter, gibt es kein problem, Sie zu bekehren zu den normalen Eigenschaften später auf.

Als Sie sagte, man könne die Felder verwenden, und wenn Sie wollte, Logik hinzufügen, um Sie später, Sie würden wandeln Sie auf Eigenschaften.Dies kann jedoch zu Problemen mit der jede Verwendung von Reflexion (und möglicherweise auch anderswo?).

Auch die Eigenschaften, mit denen Sie unterschiedliche Zugriffsebenen für die getter und setter, die Sie nicht tun können, mit einem Feld.

Ich denke, es ist das gleiche wie das Schlüsselwort var.Eine Frage der persönlichen Präferenz.

Answer 5

Von Bjarne Stroustrup, Erfinder von C++:

Ich besonders nicht mögen Klassen mit einer Menge von get-und set-Funktionen.Das ist oft ein Hinweis, dass es sollte nicht eine Klasse in den ersten Platz.Es ist nur ein Daten-Struktur.Und wenn es sich wirklich um eine Daten-Struktur, machen es zu einem Daten-Struktur.

Und wissen Sie was?Er hat Recht.Wie oft sind Sie einfach wrapping private Felder in eine get-und set, ohne tatsächlich etwas zu tun, innerhalb der get - /set, einfach weil es die "Objekt-orientiert", was zu tun ist.Dies ist Microsofts Lösung für das problem;Sie sind im Grunde öffentliche Felder, die Sie binden können.

Answer 6

Eine Sache, die niemand zu haben scheint, erwähnt wird, wie die automatische-Eigenschaften sind leider nicht nützlich für unveränderliche Objekte (in der Regel unveränderlichen Strukturen).Weil für die Sie wirklich tun sollten:

private readonly string title;
public string Title
{
    get { return this.title; }
}

(wo das Feld initialisiert im Konstruktor über eine übergebene parameter, und dann ist es nur zu Lesen.)

Das hat Vorteile gegenüber einer einfachen get/private set autoproperty.

Answer 7

Ich erstelle immer Eigenschaften anstelle von öffentlichen Feldern, denn Sie verwenden können Eigenschaften in einer interface-definition, können Sie nicht öffentliche Felder in einer interface-definition.

Answer 8

Auto-Eigenschaften sind, wie viel eine schwarze Magie ist wie alles andere in C#.Wenn Sie denken über es in Bezug auf die Zusammenstellung unten im IL eher, als dass es erweitert werden, um ein normales C# - Eigenschaft zuerst ist es ein viel weniger schwarze Magie als eine Menge von anderen Sprachkonstrukte.

Answer 9

Ich verwende auto-Eigenschaften alle die Zeit.Vor C#3 ich konnte nicht belästigt werden, mit allen Eingabe-und nur verwendet public-Variablen statt.

Das einzige, was ich vermisse, ist die Möglichkeit, dies zu tun:

public string Name = "DefaultName";

Sie haben eine Verschiebung der Standardeinstellungen in Ihren Konstruktoren mit Eigenschaften.mühsam :-(

Answer 10

Ich denke, dass jede Konstruktion, die ist intuitiv UND reduziert die Linien von code ist ein großes plus.

Diese Art von Funktionen sind genau das, was Sprachen wie Ruby so mächtig (und die dynamischen Eigenschaften, die auch helfen, reduzieren überschüssiges code).

Ruby hat diese alle zusammen als:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Answer 11

Das einzige problem, das ich habe mit Ihnen ist, dass Sie nicht weit genug gehen.Die gleiche Version des Compilers, Hinzugefügt automatische Eigenschaften, Hinzugefügt partiellen Methoden.Warum Sie nicht setzen die beiden zusammen, ist mir schleierhaft.Ein einfaches "teilweise Auf<PropertyName>Verändert" hätte diese Dinge wirklich, wirklich nützlich.

Answer 12

Es ist einfach, es ist kurz, und wenn Sie wollen, um eine effektive Umsetzung in der Eigenschaft der Körper irgendwo auf der ganzen Linie, es wird nicht Pause Ihre Art die externe Schnittstelle.

So einfach ist das.

Answer 13

Eine Sache zu beachten hier ist, dass, nach meinem Verständnis ist dies nur syntaktischer Zucker auf C# 3.0 Ende, was bedeutet, dass die IL generiert der compiler ist der gleiche.Ich bin über die Vermeidung der schwarzen Magie, die aber alle das gleiche, weniger Linien für die gleiche Sache, ist in der Regel eine gute Sache.

Answer 14

Meiner Meinung nach sollte man immer mit auto-Eigenschaften anstelle von öffentlichen Feldern.Dieser sagte, hier ist ein Kompromiss:

Beginnen Sie mit einer interne Feld mit der Namenskonvention, die Sie verwenden würden, für eine Eigenschaft.Wenn Sie zunächst entweder

• benötigen Zugriff auf den Bereich außerhalb seiner Versammlung, oder
• müssen Logik hinzufügen einer getter/setter

Tun Sie dies:

1. benennen Sie das Feld
2. machen Sie es privat
3. fügen Sie eine öffentliche Eigenschaft

Ihr client-code nicht ändern müssen.

Eines Tages, obwohl, Ihr system wird wachsen und du wirst zerlegen ihn in einzelne Baugruppen und mehrere Lösungen.Wenn das passiert, werden alle sichtbaren Felder wird wieder kommen um dich heimzusuchen, weil, wie Jeff bereits sagte, das ändern eines öffentlichen Feld zu einer öffentlichen Eigenschaft ist eine bedeutende API ändern.

Answer 15

Ich benutze CodeRush, es ist schneller als auto-Eigenschaften.

Um dies zu tun:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

Erfordert acht Tastenanschläge insgesamt.

Answer 16

Auch mit code-snippets eine auto-Eigenschaft mit dem gleichen Namen sieben Anschläge in total ;)

Answer 17

@Dominic :Ich verstehe es nicht..können Sie nicht, tun Sie dies mit auto-Eigenschaften?:

public string Title { get; }

oder

public string Title { get; private set; }

Ist es das, was Sie sich beziehen?

Answer 18

Mein größtes Problem mit auto-Eigenschaften ist, dass Sie entworfen sind, um Zeit zu sparen, aber oft finde ich, habe ich, um Sie zu erweitern in vollständige geblasen Eigenschaften später.

Was VS2008 fehlt ist ein Explodieren Auto-Eigenschaft umgestalten.

Die Tatsache, dass wir haben eine Kapseln Feld umgestalten lässt die Art, wie ich schneller arbeiten, um Sie nur öffentliche Felder.