Ich habe Klassen, die nur automatische Eigenschaften haben wie public customerName {get; einstellen;}. Sie sind öffentlich, weil sie außerhalb der Klasse aufgerufen werden. Sie können auch innerhalb der Klasse aufgerufen werden. Sie bieten eine gute Kapselung und besseres Debugging. Ich kann einen Breakpoint auf einen setzen, wenn ich wissen muss, wer wann darauf zugreift.
Meine Frage ist, was sind die Nachteile der Verwendung von Eigenschaften nur ohne entsprechende Felder? Ich kann den Setter oder Getter privat, intern usw. machen, was bedeutet, dass ich auch die Flexibilität habe, es bei Bedarf zu definieren.
Serialisierung mit BinaryFormatter - Sie haben große Probleme, wenn Sie Ihre Eigenschaft später in eine "normale" Eigenschaft ändern müssen, um z. B. eine Validierung / Eventing / etc hinzuzufügen - sinc BinaryFormatter verwendet die Feldnamen. Und Sie können das nicht duplizieren, da der Feldname, den der Compiler generiert, nicht als legales C # geschrieben werden kann.
Dies ist ein guter Grund, stattdessen einen Contract-basierten Serializer zu betrachten. Weitere Informationen finden Sie in diesem Blogeintrag .
Sie können keine Eigenschaft wirklich nur lesen erstellen, da Sie sowohl Setter als auch Getter definieren müssen. Sie können den privaten Setter nur verwenden, um eine pseudo-readonly-Eigenschaft von außen zu erhalten.
Ansonsten, wie oben erwähnt, gibt es keine anderen Nachteile.
Es gibt keine Nachteile für einfache Eigenschaften. Der Compiler erstellt das Backing-Feld für Sie. Dieser Blog-Eintrag wird erklärt wie der Compiler automatisch implementierte Eigenschaften behandelt.
Nicht wirklich ein Nachteil, aber Sie müssen die Standardwerte der automatischen Eigenschaften beachten. Mit "klassischen" Eigenschaften haben wir immer die Hintergrundfelder initialisiert, z. so:
%Vor%Dies machte es offensichtlich, was der Standardwert der Eigenschaft ist.
Bei automatischen Eigenschaften müssen Sie wissen, welche Standardwerte für die verschiedenen Typen gelten (z. B. false für bool). Wenn Sie nicht möchten, dass die Eigenschaft den Standardwert hat, müssen Sie sie im Konstruktor initialisieren:
%Vor%Dies bedeutet, dass Sie einen Konstruktor implementieren müssen , wenn Sie Ihre Eigenschaften auf nicht standardmäßige Werte initialisieren möchten oder wenn eine Eigenschaft ein Referenztyp (Klasse) ist.
Aber wie ich geschrieben habe, halte ich das nicht für einen Nachteil, nur etwas, das du wissen musst.
Die Sache ist, dort ist ein entsprechendes Feld. Sie sehen es nur nicht, weil der Compiler es für Sie erstellt. Automatische Eigenschaften sind nur syntaktische Zucker oder Kurzform, um das Feld zu erstellen.
Keine wichtigen Dinge. Randfälle wie zB, wo Sie eine Eigenschaft an eine Methode übergeben müssen, bei der der Parameter als Referenz übergeben wird ( ref oder out ), was mit einer Eigenschaft nicht möglich ist (weil intern nur get_Property / set_Property-Methoden verwendet werden) implementiert durch den Compiler, keine speziellen Felder irgendeiner Art) und Sie würden ein explizites privates Unterstützungsfeld dafür benötigen.
EDIT: Oh, und die 'no readonly ' Eigenschaften, die eigentlich ziemlich häufig ist.
Wenn Sie keine spezielle Logik in den get- und / oder set-Zugriffsmethoden ausführen müssen, gibt es keinen Nachteil ...
Ich sage, dass sie vom Standpunkt der Codelesbarkeit schlecht sind. Syntax Sugar ist gut zum Schreiben von Code, aber schrecklich zum Lesen von Code. Als Entwickler wird der Code, den wir hinter uns lassen, letztendlich von einem armen Entwickler geerbt, der aus dem, was wir gemacht haben, und dem, was im Code vor sich geht, einen Sinn ergeben muss. Ich bin wirklich dagegen, eine Sprache zu ändern, um einfach Tastenanschläge zu speichern, wenn es eine etablierte Syntax für die gleichen Konstrukte gibt.