2009-08-01 19 views
0
Public Class FooBar 
{ 
    private int _foo; 

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

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

クラス内のフィールドまたはプロパティ(存在する場合)にアクセスすることは、より受け入れられていますか?私はいつもフィールドにアクセスする習慣を持っていましたが、INotifyPropertyChangedがたくさんあるWPFを行っていたので、通知に変更を加えるためにPropertyにアクセスする必要がありました。だから、私はクラス全体でフィールドとプロパティの両方のアクセスを混在させていますが、コンパイラの観点からは、スタイルや読みやすさは問題ではありません。宣言クラス内のフィールドまたはプロパティへのアクセス

答えて

2

確かにプロパティへのアクセスが意味をなさないケースがあります(たとえば、プロパティ自体を実装している場合など)。これらのケースを脇に置くと、(私は特別な理由がない限り)デフォルトでプロパティスタイルを使用します。プロパティを使用してフィールドにアクセスすると、すべての変更が単一のコードパスに送られ、実装とデバッグが簡単に変更され、エラーが発生しにくくなります。

+0

私が以前のすべてのフィールドにアクセスすることに不快感を感じたのは、単一のコードパスが大きな理由です。私がフィールドを使い始めてから、たくさんのプロパティアクセスを追加してから、後でプロパティセッターにいくつかの機能を追加すると、プロパティアクセスがそれに当たるが、すべてのフィールドアクセスはそうではない。 – kenwarner

2

これは多くが個人的なスタイルになります。ここには100%の間違いはありません。

私の好みは、プロパティへのアクセスに破ることができるように容易になり、デバッグの理由

  • のカップルのためのプロパティを使用して毎回行くと値のすべての取得/セットを確認することです。フィールドでは不可能
  • 一貫性:自動プロパティなどの場合によっては、直接バッキングフィールドに移動することはできません。毎回プロパティを調べると、同じコードが同じ値にアクセスしています。
  • パフォーマンス:単純なプロパティはです。はJITによってインライン化されるため、パフォーマンスの問題は通常はミュートポイントです。
関連する問題