単一責任の原則:変更する理由の粒度

Question

単一責任の原則を適用し、クラスの変更理由を検討する場合、その変更理由が粒度が細かすぎるか、粒度が十分でないかをどのように判断しますか?

Answer 1

「あなたの経験に基づいて、あなたの判断を適用する」以外に、これに良い答えがあることを知りません。それに失敗して、助けを得てください、それはあなたがここでしていることだと思います;）

しかし真剣な話、単純な仕事のように見えることを実行するために数十億のクラスを作成していることに気付いた場合は、おそらく粒度が高すぎるでしょう。クラスがすべて巨大に見える場合は、おそらく大雑把すぎるでしょう。当たり前のことを言っているのならご容赦ください。

これは、なぜ人間のプログラマーが必要なのかを示す、あいまいで厳格なルールのないケースの 1 つだと思います。何かを試してバランスをとり、どちらかの方向に進みすぎていると感じたらリファクタリングしてください。そして覚える： やる価値があるなら、悪いことをする価値もある.

Answer 2

1. 最初は粒度についてはあまり心配しません。私は最初はより広いレベルで懸念事項を分離することにします。基本的なポイントは、ここでオーバーエンジニアリングを避ける必要があるということです。でも十分です。同意する ルーカス この最初のステップは経験とともに改善されます。
2. 要件が変化し、「臭い」がわかり始め、問題の理解が進むにつれて、個別の懸念事項が明らかになったら、それらを取り除いて設計をリファクタリングします。基本的に、関心の分離も全体のデザインと同様に進化するものとします。