Öffentliche Felder versus automatische Eigenschaften

Question

Oft wird uns gesagt, wir sollten die Kapselung schützen, indem wir Getter- und Setter-Methoden (Eigenschaften in C#) für Klassenfelder erstellen, anstatt die Felder der Außenwelt preiszugeben.

Aber es gibt viele Fälle, in denen ein Feld nur dazu da ist, einen Wert zu speichern, und keine Berechnungen zum Abrufen oder Setzen erfordert. In diesen Fällen würden wir alle diese Nummer verwenden:

public class Book
{
    private string _title;

    public string Title
    {
          get => _title; 
          set => _title = value;
    }
}

Nun, ich muss gestehen, dass ich es nicht ertragen konnte, das alles zu schreiben (es ging nicht darum, es zu schreiben, sondern darum, es anzusehen), also bin ich abtrünnig geworden und habe öffentliche Felder verwendet.

Dann kommt C# 3.0 und ich sehe, dass sie automatische Eigenschaften hinzugefügt haben:

public class Book
{
    public string Title { get; set; } 
}

Das ist aufgeräumter, und ich bin dankbar dafür, aber was ist wirklich so anders als ein öffentliches Feld zu machen?

public class Book
{
    public string Title;
}

Answer 1

Eine Sache, die Sie mit Feldern tun können, aber nicht mit Eigenschaften (oder früher nicht konnten ... dazu komme ich gleich), ist, dass Felder als readonly Eigenschaften hingegen nicht. Mit Feldern können Sie also eindeutig angeben, dass eine Variable nur bei der Instanziierung eines Objekts (im Konstruktor) gesetzt werden soll und danach nicht mehr geändert werden darf. Ja, man kann eine Eigenschaft so einstellen, dass sie einen privaten Setter hat, aber das sagt nur aus, dass sie nicht von außerhalb der Klasse geändert werden darf, was nicht dasselbe ist wie "sie darf nach der Instanziierung nicht mehr geändert werden" - man kann sie immer noch nach der Instanziierung von innerhalb der Klasse ändern. Und ja, man kann das zugrundeliegende Feld einer Eigenschaft als "readonly" festlegen, aber das führt dazu, dass Versuche, es nach der Instanziierung zu ändern, eher zu Laufzeitfehlern als zu Fehlern bei der Kompilierung führen. Readonly Fields haben also etwas Nützliches getan, was Properties nicht können.

Das ändert sich jedoch mit C# 9, wodurch wir diese hilfreiche Syntax für Properties erhalten:

public string Height { get; init; }

die besagt, dass "dies von außerhalb der Klasse verwendet werden kann, aber nur bei der Initialisierung des Objekts gesetzt werden darf", woraufhin der Vorteil der Readonly-Funktion von Fields verschwindet.

Answer 2

Wenn Sie später prüfen wollen, ob der Titel eindeutig ist, indem Sie ihn mit einer Sammlung oder einer Datenbank vergleichen, können Sie das in der Eigenschaft tun, ohne den davon abhängigen Code zu ändern.

Wenn Sie sich nur für ein öffentliches Attribut entscheiden, haben Sie weniger Flexibilität.

Die zusätzliche Flexibilität, ohne den Vertrag zu brechen, ist für mich das Wichtigste bei der Verwendung von Eigenschaften, und solange ich die Flexibilität nicht wirklich brauche, ist die automatische Generierung am sinnvollsten.

Answer 3

Eine Sache, die ich finde sehr nützlich, sowie alle Code und Testen Gründe ist, dass, wenn es eine Eigenschaft vs ein Feld ist, dass die Visual Studio-IDE zeigt Ihnen die Referenzen für eine Eigenschaft, aber nicht ein Feld.

Answer 4

Meine Meinung nach einigen Recherchen

1. Validierung.
2. Erlaubt das Überschreiben des Accessors, um das Verhalten einer Eigenschaft zu ändern.
3. Zum Zwecke der Fehlersuche. Wir werden in der Lage sein zu wissen, wann und was die Eigenschaft ändern, indem Sie einen Haltepunkt in den Accessor.
4. Wir können ein Feld nur setzen. Zum Beispiel: public set() und private get(). Dies ist bei einem öffentlichen Feld nicht möglich.

Es gibt uns wirklich mehr Möglichkeiten und Erweiterungsmöglichkeiten.