すべての C# 静的アナライザーは、パブリック フィールドが表示されると文句を言いたがるようです。しかし、なぜ?確かに、パブリック (または内部)フィールドで十分な場合があり、プロパティとそのメソッドget_
を使用しても意味がありませんか? set_
フィールドを再定義したり、フィールドに追加したりしないことが確実にわかっている場合 (副作用は悪いことですよね?) - 単純なフィールドで十分ではないでしょうか?
8 に答える
カプセル化が破られるため、ほとんどの人がアクセサーを多用するのはこのためです。ただし、それがタスクに適切な解決策であると思われる場合は、それを無視して(厳密なカプセル化の苦情を意味します)、プロジェクトに適切なことを実行してください。OOナチスに他のことを言わせないでください。
それは本当にあなたのコードを将来にわたって保証することです。あなたが言うとき(私の強調):
フィールドを再定義したり追加したりしないことが確実にわかっている場合はどうなりますか(副作用は悪いですよね?)-単純なフィールドで十分ではありませんか?
これは絶対的なステートメントであり、私たちが知っているように(そしてほとんどの静的アナライザーも)、人生には絶対的なものは2つしかありません。
それはあなたをそれから守ろうとしているだけです。それが問題である場合は、アナライザーにそれを無視するように指示できるはずです(使用している分析ツールに依存する属性を介して)。
現在のC#3.0では、構文が次のような自動プロパティが許可されているという事実を前提としています。
public int Property {get; set;}
パブリックフィールドでプロパティを使用するために必要な余分な作業はほとんどありません。重要なのは、フィールドが別の方法で使用されないこと、またはアクセサーが変更されないこと、そして作業のトレードオフを考えると、プロパティを実装しない理由がないことを完全に確信することはできないということです。
とにかく、アナライザーは、高い割合(この場合は99.99%のケースのように)が悪いプログラミング慣行であるということについて不平を言います...しかしとにかくそれはただ不平を言っています。フィールドは公開することができ、その直接使用が正当化される極端な場合がいくつかあります。いつものように、常識を働かせてください...しかし、プログラミングのベストプラクティスの基本的なルールを覚えておいてください...慣習を破る本当に正当な理由はありますか?先に進む場合、そうでない場合、または答えが「より多くの作業が必要」である場合は、練習に固執します...
後でパブリックフィールドを変更してget/setアクセサーを使用すると、コードが破損するためです。詳細については、この回答を参照してください
一般に、フィールドを再定義しないことを「確実に知っている」場合でも、プロパティの背後にフィールドを非表示にすることをお勧めします。多くの場合、今日「確かに知っている」ことは明日変わります。また、フィールドを参照するプロパティを作成するのは少し面倒です。
とはいえ、静的アナライザーは思考に代わるものではありません。設計に満足していて、アナライザーが間違っていると判断した場合は、その状況でその警告を無視するか、(可能であれば)抑制してください。
重要なのは、一般的に、フィールドを再定義したり、後でフィールドに追加したりしないかどうかはわからないということです。データをカプセル化して非表示にすることの全体的なポイントは、パブリックインターフェイスを変更したり、依存クラスを壊したりすることなく、これらのことを自由に実行できることです。プロパティアクセサーが単純なget/setである場合は、とにかくコンパイルされるので、パフォーマンスの問題はありません。これを考えると、プロパティアクセサーを使用しない正当な理由があるのでしょうか?
プロパティがテーブルにもたらすもう1つの利点は、Reflectionを実行するときです。クラスを振り返ると、プロパティとフィールドを取得するのではなく、すべてのプロパティを1回のショットで取得できます。
また、アクセサーを使用すると、複数のスレッドを操作するときに柔軟性が得られることを忘れないでください。