単一責任の原則、分解などに関するこれらすべての読み物では、エンティティが肥大化するというアラーム信号がどうあるべきかを理解することは困難です。
最大数の方法を検討する必要があるか、または他の客観的な基準があるかどうかについて、どこかに良いアドバイス/読み物がありますか？
1 に答える
1
私の意見では、 SOLIDの原則は厳密なルールとしてではなく、ガイドラインとして扱われるべきです。通常、SOLID 違反は、設計上の問題の信頼できる指標です。しかし、それらは時には避けられないものです。
かなりの数のコード メトリクスがあります。NDependsから:
NbMethods: (アプリケーション、アセンブリ、名前空間、型に対して定義) メソッドの数。メソッドは、抽象メソッド、仮想メソッド、または非仮想メソッド、インターフェイスで宣言されたメソッド、コンストラクター、クラス コンストラクター、ファイナライザー、プロパティ/インデクサーのゲッターまたはセッター、イベントの追加者またはリムーバーです。サードパーティのアセンブリで宣言されたメソッドは考慮されません。
推奨事項: NbMethods > 20 の型は理解と維持が難しいかもしれませんが、NbMethods に高い値を持つことが関連する場合があるかもしれません。たとえば、System.Windows.Forms.DataGridView サードパーティ クラスには 1000 を超えるメソッドがあります。
20 は、NDepends の作成者が妥当なしきい値であると見なした値です。異議申し立てからの別の意見は次のとおりです。
この値は3 から 7 の間でなければなりません。これは、クラスに操作があるが、多すぎないことを示します。7 より大きい値は、さらにオブジェクト指向の分解が必要であること、またはクラスに一貫した目的がないことを示している可能性があります。2 以下の値は、これが実際にはクラスではなく、単なるデータ構造であることを示します。
ご覧のとおり、これらの指標は非常に主観的です。したがって、あなたとあなたのチームにとって何が理にかなっているのかを判断する必要があります。DDD の観点から、値オブジェクトを使用することは、エンティティの SRP 違反を減らすための非常に優れたアプローチであることがわかりました。
于 2011-09-03T17:25:08.337 に答える