3

自動プロパティを使用して、クリーンでコードの少ないクラスを使用したい。プロパティはすべてパブリックです。同じクラスのメソッド内で、そのプロパティも使用しました。したがって、内部使用とパブリック使用にパブリック プロパティを使用するため、このアプローチはマッシュ可能であると思います。このような状況での最善のアプローチは何ですか? メソッド内でプライベート メンバーを使用し、パブリックで使用するプロパティを作成するか、クラス内でパブリック (または特別な状況ではプライベート) プロパティを使用しますか?

public class Account
{
     public int Count {get; set;}

     private int Calculate()
     {
         return Count * Count;
     }
}

またはこのようなものを使用します

public class Account
{
     private int _count;
     public int Count {
        get
        {
            return _count;
        } 
        set
        {
            _count = value,
        }
     }

    private int Calculate()
    {
        return _count * _count;
    }
}
4

5 に答える 5

2

最初の方法が望ましいと思います。単純な変数ではなく、概念を公開しています。つまり、消費するコードを変更することなく、後でその概念の定義を簡単に変更できます。

実際、2番目のケースを明示的に回避するために、フィールドを必要とするプロパティのみがフィールドにアクセスできるようにする方法があればいいのにと思います。

于 2012-09-06T22:05:04.787 に答える
2

最初の方法は、2 番目の方法で書いたものなので、まったく問題ありません。ただし、getter または setter に追加のコードを追加する必要がある場合は注意してください。

于 2012-09-06T22:01:32.323 に答える
2

パブリック プロパティを内部的にも外部的にも使用することは完全に許容されます。特に、プロパティにロジックがないために自動プロパティである場合はそうです。そして、それはよりクリーンなコードであるため、好ましい方法だと思います。

ところで: コードがコンパイルされると、バッキング フィールドが作成されるため、両方の例の IL コードは同じです。したがって、自動プロパティは、設計時の開発者の使いやすさの機能にすぎません。

自動プロパティの getter の IL コード...

.method public hidebysig specialname instance int32 
    get_Count() cil managed
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) 
  // Code size       11 (0xb)
  .maxstack  1
  .locals init (int32 V_0)
  IL_0000:  ldarg.0
  IL_0001:  ldfld      int32 ConsoleApplication1.Program::'<Count>k__BackingField'
  IL_0006:  stloc.0
  IL_0007:  br.s       IL_0009
  IL_0009:  ldloc.0
  IL_000a:  ret
} // end of method Program::get_Count

バッキング フィールドを持つプロパティの getter の IL コード ...

.method public hidebysig specialname instance int32 
    get_Count() cil managed
{
  // Code size       12 (0xc)
  .maxstack  1
  .locals init ([0] int32 CS$1$0000)
  IL_0000:  nop
  IL_0001:  ldarg.0
  IL_0002:  ldfld      int32 ConsoleApplication1.Program::_count
  IL_0007:  stloc.0
  IL_0008:  br.s       IL_000a
  IL_000a:  ldloc.0
  IL_000b:  ret
} // end of method Program::get_Count
于 2012-09-06T22:02:57.017 に答える
0

ゲッターとセッターは非常に使いすぎです。public フィールドは悪であると主張する何百万人もの人々を見てきました。これは、フィールドをパブリックにすることとほぼ同じであると思いますが、スレッドを使用している場合 (ただし、一般的にはそうではありません)、またはアクセサーにビジネス/プレゼンテーション ロジックがある場合 (少なくとも「奇妙な」もの) は少し異なるかもしれません。私は public フィールドには賛成ではありませんが、すべての getter/setter (または Property) を作成し、それを行うことはカプセル化または情報隠蔽であると主張することには反対です... ハ! Pablo Fernandez参照: this および 19 の他の物議を醸すプログラミング意見

この質問に答えるために、私は両方を使用しましたが、最初のオプションが最も簡単です。質問に答えるのが少し難しいのは、プロパティのゲッター/セッター内でなんらかの副作用が発生した場合です。典型的な例は、プロパティが変更されたことを示すためにイベントが発生した場合です。それはクラス内と外部リクエストの両方から発生する可能性がありますか? その場合、バッキング変数ではなくプロパティを使用すると、一貫した動作が得られます。したがって、最良の答えはそれによって異なります:-)

于 2012-09-07T02:22:27.223 に答える
0

ここで問題が発生することはありません。つまり、public内部でプロパティを使用するということです。プロパティがフィールドに関して非常に小さなオーバーヘッドを導入することはよく知られていますが、99.99%場合によってはそれが無関係であるため、ここでは重要ではないと思います。

要するに、最初のケースは問題ありません。

これもTDD設計の観点から考えてみてください。public(TDD のベスト プラクティスに従って) メンバーをテストする場合は、「内部」機能への影響もテストできます。

于 2012-09-06T22:02:43.337 に答える