Zugriff auf Felder oder Eigenschaften innerhalb der deklarierenden Klasse

Question

Public Class FooBar 
{ 
    private int _foo; 

    public int Foo { 
     get { return _foo; } 
     set { _foo = value; } 
    } 

    public void DoStuff() 
    { 
     _foo++; // Do this? 
     Foo++; // Or this? 
    } 
} 

Gibt es eine akzeptierte Praxis, entweder auf Felder oder Eigenschaften (falls vorhanden) in einer Klasse zuzugreifen? Ich war schon immer daran gewöhnt, auf das Feld zuzugreifen, aber seit ich WPF gemacht habe, das viele INotifyPropertyChanged hat, musste ich auf die Eigenschaft zugreifen, um die Benachrichtigung zu ändern. So, jetzt habe ich eine Mischung aus Feld-und Eigentum Zugriffen in meinen Klassen und während aus Sicht eines Compilers ist es egal, stilistisch und Lesbarkeit, es fühlt sich ... peinlich.

Answer 1

Es gibt sicherlich Fälle, in denen der Zugriff auf die Eigenschaft nicht sinnvoll ist (z. B. wenn Sie die Eigenschaft selbst implementieren). Wenn ich diese Fälle beiseite lege, würde ich standardmäßig den Eigenschaftsstil wählen (es sei denn, ich habe einen bestimmten Grund, dies nicht zu tun). Durch den Zugriff auf das Feld über die Eigenschaft werden alle Änderungen in einen einzigen Codepfad geleitet, wodurch die Implementierung und das Debugging vereinfacht und weniger fehleranfällig werden.

Answer 2

Eine Menge davon kommt auf den persönlichen Stil. Es gibt keine 100% richtige oder falsche Antwort hier.

Meine Präferenz ist durch die Eigenschaft jedes Mal für ein paar Gründe

• Bildet das Debuggen einfacher zu gehen, wie Sie auf Eigentum Zugang zu brechen und all get/set des Wertes zu sehen. Nicht möglich mit einem Feld
• Konsistenz: In einigen Fällen, wie Auto-Eigenschaften, ist es nicht möglich, direkt zum Hintergrundfeld zu gehen. Wenn Sie jedes Mal durch die Eigenschaft gehen, wird derselbe Code angezeigt, der auf denselben Wert zugreift.
• Leistung: Einfache Eigenschaften sind wahrscheinlich inlined von der JIT so das Leistungsproblem ist in der Regel ein Mute-Punkt.