c# - Get メソッドのサイズ

Question

コードの行数に関して、「Get」のサイズに関するガイドラインや一般的なコンセンサスはありますか? ここでは、30 行のコードに非常に簡単に成長したメンバーに Get メソッドがあります。これがどの時点でメソッドに引き出されるべきかわかりません。しかし、私はそれを GetMyString のようなものと呼び、その値を別のメンバーに割り当てて、とにかくコンストラクターで呼び出すだけです。

これを行う価値はありますか？

これはSOにとって主観的すぎますか？

Answer 1

dcastroの答えは良いですが、いくつかの拡張を使用できます:

• 戻るのに時間がかからない

それは定量化されていません。それを数値化しましょう。プロパティは、フィールドのフェッチにかかる時間の 10 倍以上かかるべきではありません。

• 外部リソース (データベース、サービスなど) には接続しません。

これらは遅いため、通常は最初のルールに当てはまりますが、これには 2 つ目の側面があります。プロパティ ゲッターは例外をスローしないでください。

• 副作用はありません

観察可能な副作用について明確にします。プロパティの getter には、プロパティを一度計算して後でキャッシュするという副作用がよくありますが、これは目に見える副作用ではありません。

プロパティに目に見える副作用を持たせることは哲学的に悪いだけでなく、デバッグ体験を台無しにする可能性もあります。デフォルトでは、デバッガーでオブジェクトを見ると、デバッガーはそのプロパティ ゲッターを自動的に呼び出し、結果を表示することに注意してください。これが遅い場合は、デバッグが遅くなります。これが失敗する可能性がある場合、デバッグ エクスペリエンスは失敗メッセージでいっぱいになります。副作用がある場合、プログラムをデバッグするとプログラムの動作が変わり、バグを見つけるのが非常に難しくなる可能性があります。もちろん、プロパティの自動評価をオフにすることもできますが、最初から適切なプロパティを設計することをお勧めします。

Answer 2

重要なのはサイズではありません (しゃれは意図されていません)。ロジックを getter に入れても問題ありません。

• 戻るのに時間がかからない
• 外部リソース (データベース、サービスなど) には接続しません。
• 副作用はありません

これらは、プロパティを適切に使用するためのガイドラインの一部にすぎません。

編集

上記のガイドラインは、1 つの理想を共有しています。プロパティ アクセサーはデータ アクセスのように動作する必要があります。これは、ユーザーが期待することだからです。

Bill Wagner 著『Effective C#』より:

プロパティは、データのように呼び出し元のコードから表示できるメソッドです。これにより、ユーザーの頭にいくつかの期待が生じます。プロパティへのアクセスは、データへのアクセスであるかのように見えます。結局、それはそれがどのように見えるかです。プロパティ アクセサーは、これらの期待に応える必要があります。Get アクセサーには、目に見える副作用があってはなりません。Set アクセサーは状態を変更し、ユーザーはそれらの変更を確認できる必要があります。

プロパティ アクセサーには、ユーザーに対するパフォーマンスの期待もあります。プロパティへのアクセスは、データ フィールドへのアクセスに似ています。単純なデータ アクセスとは大幅に異なるパフォーマンス特性を持つべきではありません。

プロパティ アクセサーは、時間のかかる計算を実行したり、アプリケーション間の呼び出し (データベース クエリの実行など) を行ったり、プロパティ アクセサーに対するユーザーの期待と矛盾するその他の時間のかかる操作を実行したりしないでください。

アルベルトによるボーナス: http://msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx

Answer 3

必ずしも悪いわけではありませんが、私だったら緊張してしまい、どうにか打破したいと思います。ゲッターはメソッドなので、単純にすべてを 30 行以上のメソッドに引き込むのは時間の無駄だと思います。私はそれを切り刻もうとしていたでしょう。たとえば、いくつかのチェックを含むループの場合、チェックをメソッドなどとして抽出します。

Answer 4

一般的なガイドラインとして、1 つの画面に収まるよりも多くの行をメソッドに含めるべきではありません。スクロールする必要がある場合は、大きすぎます。より小さなメソッドに分割します。