C # 3.0 Auto-Eigenschaften - nützlich oder nicht? [geschlossen]

Hinweis: Dies wurde gepostet, als ich mit C # anfing. Mit dem Wissen von 2014 kann ich wirklich sagen, dass Auto-Eigenschaften zu den besten Dingen gehören, die jemals mit der C # -Sprache passiert sind.

Ich bin es gewohnt, meine Eigenschaften in C # mithilfe eines privaten und eines öffentlichen Felds zu erstellen:

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

Mit .NET 3.0 haben wir jetzt automatische Eigenschaften:

public string Title { get; set; }

Ich weiß, dass dies eher eine philosophische / subjektive Frage ist, aber gibt es einen Grund, diese Auto-Eigenschaften zu verwenden, außer fünf Codezeilen für jedes Feld zu speichern? Mein persönlicher Kritikpunkt ist, dass diese Eigenschaften Dinge vor mir verbergen, und ich bin kein großer Fan von schwarzer Magie.

Tatsächlich wird das versteckte private Feld nicht einmal im Debugger angezeigt, was in Ordnung ist, da die Funktionen get / set nichts bewirken. Aber wenn ich tatsächlich eine Getter / Setter-Logik implementieren möchte, muss ich trotzdem das private / öffentliche Paar verwenden.

Ich sehe den Vorteil, dass ich viel Code speichere (eine gegen sechs Zeilen), ohne die Fähigkeit zu verlieren, die Getter / Setter-Logik später zu ändern, aber andererseits kann ich das bereits tun, indem ich einfach ein öffentliches Feld "Public string Title" ohne deklariere die Notwendigkeit des {get; einstellen; } blockieren und somit sogar mehr Code speichern.

Also, was vermisse ich hier? Warum sollte jemand eigentlich Auto-Eigenschaften verwenden wollen?

Wir verwenden sie ständig im Stapelüberlauf.

Möglicherweise interessiert Sie auch eine Diskussion über Eigenschaften im Vergleich zu öffentlichen Variablen . IMHO ist das wirklich eine Reaktion darauf und zu diesem Zweck ist es großartig.

Ja, es wird nur Code gespeichert. Es ist meilenweit einfacher zu lesen, wenn Sie viele davon haben. Sie sind schneller zu schreiben und einfacher zu warten. Das Speichern von Code ist immer ein gutes Ziel.

Sie können verschiedene Bereiche festlegen:

public string PropertyName { get; private set; }

Damit kann die Eigenschaft nur innerhalb der Klasse geändert werden. Dies ist nicht wirklich unveränderlich, da Sie immer noch durch Reflexion auf den privaten Setter zugreifen können.

Ab C # 6 können Sie auch echte readonlyEigenschaften erstellen, dh unveränderliche Eigenschaften, die außerhalb des Konstruktors nicht geändert werden können:

public string PropertyName { get; }

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

Zur Kompilierungszeit wird dies:

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

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

In unveränderlichen Klassen mit vielen Mitgliedern spart dies viel überschüssigen Code.

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

1. Sie können nicht an ein Feld binden, wohingegen Sie an eine Eigenschaft
2. Wenn Sie zunächst ein Feld verwenden, können Sie es später (einfach) nicht in eine Eigenschaft ändern
3. Es gibt einige Attribute, die Sie einer Eigenschaft hinzufügen können, die Sie einem Feld nicht hinzufügen können

Ich persönlich liebe Auto-Eigenschaften. Was ist falsch daran, die Codezeilen zu speichern? Wenn Sie Dinge in Getter oder Setter tun möchten, ist es kein Problem, sie später in normale Eigenschaften umzuwandeln.

Wie Sie sagten, könnten Sie Felder verwenden, und wenn Sie ihnen später Logik hinzufügen möchten, würden Sie sie in Eigenschaften konvertieren. Dies kann jedoch zu Problemen bei der Verwendung von Reflexion führen (und möglicherweise auch anderswo?).

Mit den Eigenschaften können Sie auch verschiedene Zugriffsebenen für den Getter und den Setter festlegen, die Sie mit einem Feld nicht ausführen können.

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

Von Bjarne Stroustrup, dem Erfinder von C ++:

Ich mag keine Klassen mit vielen Get- und Set-Funktionen. Das ist oft ein Hinweis darauf, dass es überhaupt keine Klasse sein sollte. Es ist nur eine Datenstruktur. Und wenn es sich wirklich um eine Datenstruktur handelt, machen Sie sie zu einer Datenstruktur.

Und weisst du was? Er hat recht. Wie oft wickeln Sie einfach private Felder in ein get and set ein, ohne tatsächlich etwas innerhalb des get / set zu tun, einfach weil es die "objektorientierte" Sache ist, die zu tun ist. Dies ist die Lösung von Microsoft für das Problem. Es handelt sich im Grunde genommen um öffentliche Felder, an die Sie binden können.

Eine Sache, die anscheinend niemand erwähnt hat, ist, dass Autoeigenschaften für unveränderliche Objekte (normalerweise unveränderliche Strukturen) leider nicht nützlich sind. Denn dafür solltest du wirklich tun:

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

(wobei das Feld im Konstruktor über einen übergebenen Parameter initialisiert und dann schreibgeschützt wird.)

Dies hat also Vorteile gegenüber einer einfachen get/ private setautoproperty.

Ich erstelle immer Eigenschaften anstelle von öffentlichen Feldern, weil Sie Eigenschaften in einer Schnittstellendefinition verwenden können, Sie können keine öffentlichen Felder in einer Schnittstellendefinition verwenden.

Auto-Eigenschaften sind genauso eine schwarze Magie wie alles andere in C #. Wenn Sie erst einmal darüber nachdenken, wie Sie zu IL kompilieren können, anstatt es zuerst zu einer normalen C # -Eigenschaft zu erweitern, ist es viel weniger schwarze Magie als viele andere Sprachkonstrukte.

Ich benutze die ganze Zeit Auto-Eigenschaften. Vor C # 3 konnte ich mich nicht mit der ganzen Eingabe beschäftigen und verwendete stattdessen nur öffentliche Variablen.

Das einzige, was ich vermisse, ist, dies tun zu können:

public string Name = "DefaultName";

Sie müssen die Standardeinstellungen in Ihre Konstruktoren mit Eigenschaften verschieben. langweilig :-(

Ich denke, jedes Konstrukt, das intuitiv ist UND die Codezeilen reduziert, ist ein großes Plus.

Diese Art von Funktionen macht Sprachen wie Ruby so leistungsfähig (diese und dynamische Funktionen, die auch dazu beitragen, überschüssigen Code zu reduzieren).

Ruby hatte dies die ganze Zeit als:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

Das einzige Problem, das ich mit ihnen habe, ist, dass sie nicht weit genug gehen. Dieselbe Version des Compilers, die automatische Eigenschaften hinzugefügt hat, hat Teilmethoden hinzugefügt. Warum sie die beiden nicht zusammengefügt haben, ist mir ein Rätsel. Ein einfaches "partielles On <PropertyName> Changed" hätte diese Dinge wirklich sehr, sehr nützlich gemacht.

Es ist einfach, kurz und wenn Sie irgendwo auf der ganzen Linie eine echte Implementierung im Hauptteil der Eigenschaft erstellen möchten, wird die externe Schnittstelle Ihres Typs nicht beschädigt.

So einfach ist das.

Hierbei ist zu beachten, dass dies meines Wissens nur syntaktischer Zucker am C # 3.0-Ende ist, was bedeutet, dass die vom Compiler generierte IL dieselbe ist. Ich bin damit einverstanden, schwarze Magie zu vermeiden, aber trotzdem sind weniger Zeilen für dieselbe Sache normalerweise eine gute Sache.

Meiner Meinung nach sollten Sie immer Auto-Eigenschaften anstelle von öffentlichen Feldern verwenden. Das heißt, hier ist ein Kompromiss:

Beginnen Sie mit einem internen Feld unter Verwendung der Namenskonvention, die Sie für eine Eigenschaft verwenden würden. Wenn Sie zuerst auch

• benötigen Zugriff auf das Feld von außerhalb seiner Baugruppe, oder
• müssen Logik an einen Getter / Setter anhängen

Mach das:

1. Benennen Sie das Feld um
2. mach es privat
3. ein öffentliches Eigentum hinzufügen

Ihr Client-Code muss nicht geändert werden.

Eines Tages wird Ihr System jedoch wachsen und Sie werden es in separate Baugruppen und mehrere Lösungen zerlegen. In diesem Fall werden alle exponierten Felder zurückkehren, um Sie zu verfolgen, da das Ändern eines öffentlichen Felds in eine öffentliche Eigenschaft , wie Jeff erwähnte, eine brechende API-Änderung darstellt .

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;  }
}

Benötigt insgesamt acht Tastenanschläge.

Nun, mit Code-Schnipsel wäre eine gleichnamige Auto-Eigenschaft insgesamt sieben Tastenanschläge;)

@Domenic: Ich verstehe es nicht. Kannst du das nicht mit Auto-Eigenschaften machen?:

public string Title { get; }

oder

public string Title { get; private set; }

Beziehen Sie sich darauf?

Mein größter Kritikpunkt an Auto-Eigenschaften ist, dass sie Zeit sparen sollen, aber ich finde oft, dass ich sie später zu vollständigen Eigenschaften erweitern muss.

Was VS2008 fehlt, ist ein Refode Auto-Property Refactor.

Die Tatsache, dass wir einen gekapselten Feldrefaktor haben, macht es mir schneller, nur öffentliche Felder zu verwenden.