Ö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

Es geht um Versionierung und API-Stabilität. In Version 1 gibt es keinen Unterschied - aber wenn Sie später entscheiden, dass Sie diese Eigenschaft in Version 2 zu einer Eigenschaft mit einer Art von Fehlerprüfung machen müssen, müssen Sie Ihre API nicht ändern - es gibt keine Codeänderungen, außer der Definition der Eigenschaft.

Answer 2

Ein weiterer Vorteil von automatisch implementierten Eigenschaften gegenüber öffentlichen Feldern besteht darin, dass Sie die Zugriffsberechtigungen für Sets privat oder geschützt machen können, wodurch die Objektklasse, in der sie definiert wurden, eine bessere Kontrolle erhält als bei öffentlichen Feldern.

Answer 3

Es ist nicht falsch, ein Feld zu machen public . Aber denken Sie daran, dass Sie getter/setter avec private felder ist nicht gekapselt. IMO, Wenn Sie sich nicht um andere Merkmale einer Property können Sie es genauso gut machen public .

Answer 4

Triviale Eigenschaften wie diese machen mich traurig. Sie sind die schlimmste Art von Cargo Culting und der Hass auf öffentliche Felder in C# muss aufhören. Das größte Argument gegen öffentliche Felder ist die Zukunftssicherheit: Wenn Sie später entscheiden, dass Sie dem Getter und Setter zusätzliche Logik hinzufügen müssen, dann müssen Sie in jedem anderen Code, der das Feld verwendet, ein großes Refactoring durchführen. Dies gilt sicherlich für andere Sprachen wie C++ und Java, wo sich die Semantik für den Aufruf einer Getter- und Setter-Methode stark von der für das Setzen und Abrufen eines Feldes unterscheidet. In C# ist die Semantik für den Zugriff auf eine Eigenschaft jedoch genau dieselbe wie für den Zugriff auf ein Feld, so dass 99 % Ihres Codes davon völlig unberührt bleiben sollten.

Das einzige Beispiel, das ich gesehen habe, bei dem die Umwandlung eines Feldes in eine Eigenschaft tatsächlich eine bahnbrechende Änderung auf Quellcodeebene war, ist so etwas wie:

    TryGetTitle(out book.Title); // requires a variable

Dazu muss ich fragen, warum TF sind Sie ein Feld einer anderen Klasse als Referenz übergeben? Abhängig davon, dass es sich nicht um eine Eigenschaft handelt, scheint hier der eigentliche Fehler in der Programmierung zu sein. Die Annahme, dass Sie direkt auf Daten in einer anderen Klasse schreiben können, die Sie nicht kennen, ist eine schlechte Praxis. Erstellen Sie Ihre eigene lokale Variable und setzen Sie book.Title davon. Jeder Code, der so etwas tut, verdient es, kaputt zu gehen.

Andere Argumente, die ich dagegen gesehen habe:

• Das Ändern eines Feldes in eine Eigenschaft unterbricht die Binärkompatibilität und erfordert, dass jeder Code, der es verwendet, neu kompiliert wird: Dies ist ein Problem, wenn Sie Code für die Verteilung als Closed-Source-Bibliothek schreiben. In diesem Fall, ja, stellen Sie sicher, dass keine Ihrer benutzerseitigen Klassen öffentliche Felder haben und verwenden Sie bei Bedarf triviale Eigenschaften. Wenn Sie jedoch wie 99 % der C#-Entwickler sind und Code nur für den internen Gebrauch innerhalb Ihres Projekts schreiben, warum ist dann die Neukompilierung ein großes Problem? So gut wie jede andere Änderung, die Sie vornehmen, wird auch eine Neukompilierung erfordern, und was ist, wenn es so ist? Soweit ich weiß, ist es nicht mehr 1995, wir haben schnelle Computer mit schnellen Compilern und inkrementellen Linkern, selbst größere Rekompilierungen sollten nicht länger als ein paar Minuten dauern, und es ist schon eine ganze Weile her, dass ich "mein Code kompiliert" als Ausrede benutzen konnte, um Schwertkampf durch das Büro .
• Sie können keine Datenabbindung gegen eine Variable vornehmen: Gut, wenn Sie das tun müssen, machen Sie eine Eigenschaft daraus.
• Eigenschaften haben Funktionen, die sie besser für das Debugging machen, wie Reflection und das Setzen von Haltepunkten: Wenn Sie eine dieser Funktionen benötigen, machen Sie sie zu einer Eigenschaft. Wenn Sie mit dem Debuggen fertig sind und bereit für die Freigabe, wenn Sie diese Funktionen nicht mehr benötigen, ändern Sie es zurück in ein Feld.
• Eigenschaften ermöglichen es Ihnen, das Verhalten in abgeleiteten Klassen zu überschreiben: Wenn Sie eine Basisklasse erstellen, bei der Sie ein solches Szenario für wahrscheinlich halten, sollten Sie die entsprechenden Mitglieder zu Eigenschaften machen. Wenn Sie sich nicht sicher sind, belassen Sie es bei einem Feld und Sie können es später ändern. Ja, das wird wahrscheinlich eine Neukompilierung erfordern, aber was soll's?

Zusammenfassend lässt sich also sagen, dass es einige legitime Verwendungszwecke für triviale Eigenschaften gibt, aber sofern Sie keine Closed-Source-Bibliothek für die öffentliche Freigabe erstellen, sind Felder einfach genug, um sie bei Bedarf in Eigenschaften umzuwandeln, und eine irrationale Angst vor öffentlichen Feldern ist nur ein objektorientiertes Dogma, von dem wir uns besser befreien sollten.

Answer 5

Für mich war das Fehlen von IntelliSense, das die Referenzen anzeigt, ein absoluter Grund, keine öffentlichen Felder zu verwenden:

Die für Felder nicht verfügbar ist.