4

単一責任の原則を適用し、クラスの変更理由を調べるとき、変更の理由が細かすぎるか、細かすぎるかをどのように判断しますか?

4

2 に答える 2

1
  1. 最初は粒度についてあまり心配していませんでした。最初は、より広いレベルで関心の分離を行います。基本的なポイントは、ここでは過剰なエンジニアリングを避ける必要があるということです。しかし、それで十分です。私はここでルーカスに同意します。この最初のステップは経験によって改善されるでしょう。
  2. 要件が変化し、「匂い」が出始めているので、問題の理解が深まるにつれて、関心が明らかになったときに個別の懸念事項を除外して設計をリファクタリングします。基本的に、関心の分離も、全体的な設計と同様に進化的である必要があります。
于 2008-09-21T07:53:36.010 に答える
1

「あなたの経験に基づいて、あなたの判断を適用してください」以外に、これに対する良い答えがあるかどうかはわかりません。それができない場合は、助けを求めてください。それがあなたがここでしていることだと思います ;)

真面目な話、単純な仕事のように見えることを実行するために膨大な数のクラスを作成している場合は、おそらく細かすぎます。クラスがすべて巨大に見える場合は、おそらく粗すぎます。それが明白な声明であるならば、私を許してください。

これは、人間のプログラマーが必要な理由を示す、あいまいで厳格な規則のないケースの 1 つだと思います。バランスを求めて何かを試してみてください。一方の方向または他方の方向に行き過ぎている場合はリファクタリングしてください。そして覚えておいてください:やる価値があるなら、それは悪いことをする価値があります.

于 2008-08-26T02:13:39.487 に答える