単一の責任原則：変更理由の詳細度

Question

単一責任原則を適用してクラスの変更理由を検討すると、変更の理由があまりにも細かすぎるのか、細かすぎるのかをどのように判断しますか？

Answer 1

「あなたの経験に基づいて、あなたの判断を適用する」以外に、これには良い答えがあることはわかりません。あなたがここで何をしているのか分かりません）助けてもらえますか？

単純な仕事のようなものを作るために巨大なクラスを作成しているのであれば、おそらくあまりに細かすぎるかもしれません。あなたのクラスがすべて巨大に見える場合、あなたはおそらくあまりにも粗すぎるでしょう。それが明白な陳述なら、私を許してください。

私は人間プログラマがなぜ必要なのかを私たちに示している、これはあいまいで、ハードな、そして速いルールのケースの1つだと思います。あなたが一方向またはそれ以上に遠すぎると思ったら、何かを試して、バランスを求めて、リファクタリングをしてください。覚えておいてください：if it's worth doing, it's worth doing badly。

Answer 2

1. 最初は粒度についてあまり心配しません。当初はより広いレベルでの懸念の分離を進めます。基本的な点は、ここでは過剰工学を避けるべきだということです。しかし、十分です。私はLucasとここで同意します。この最初のステップは経験豊かになります。
2. 要件が変化するにつれて、私が「臭い」を得るようになるにつれて、問題の理解が向上するにつれ、別の懸念が明らかになるにつれて、設計をリファクタリングします。基本的に心配の分離は、全体的な設計と同様に進化的でなければならない。