クラスを分解する必要がある場合 (クラスが手に負えないほど大きくなった場合など) については、多くの経験則を聞いたことがありますが、この質問に対する具体的な答えはわかりません。
私は「ベスト プラクティス」や「コードのにおい」を探しているわけではありません。たとえば、重複したコードが表示された場合、特定の解決策が 1 つあります。基本クラスを作成するか、両方が使用できる単一のメソッドを作成して、重複したコードを削除します。これは、私が探している具体的で具体的な答えの例です。
しかし、いつクラスを 2 つ以上のクラスに分解する必要があるかは、私にはあまり明確ではありません。私の経験則は、複数の広範な責任がある場合、そのうちの 1 つをリファクタリングするというものです。しかし、これはどちらかというと「ベスト プラクティス」であり、これをより正確に突き止めたいと思います。
私が見つけた最も近いものは、単一責任の原則です。「単一責任の原則は、すべてのオブジェクトが単一の責任を持つべきであると述べています。」しかし、責任とは何ですか？それを正確にどのように定義しますか？
ボブ・マーティンは、それが「変化する理由」だと言います。具体的な例を挙げると、入力を受け取って処理し、出力を作成するアプリがあるとします。これにより、入力 (文字列または XML からの可能性があります) という 3 つの領域が変更されます。プロセッサは、そのルールで変更される可能性があります。出力は変更される可能性があります。文字列、XML、またはデータベースの可能性があります。つまり、最上位レベルで 3 つのクラスが提供されます。
繰り返しますが、議論やベスト プラクティスを探すのではなく、分解の確固たる原則があるかどうかです。あるいは、構成の確固たる原則は、それを述べるためのより良い方法かもしれません.
分解の背後にある私にとっての動機は構成です。高度に構成されたアプリは、はるかに柔軟で操作しやすいことがわかりました。
分解するもう 1 つの理由は、開発者として、クラスを見るだけでアプリケーション全体をよりよく理解できるようにするためです。クラスを明確に理解するには、そのクラスが単一の明確な目的を持っている必要があると思います。これはクラスの命名に関係していますが、クラスにそのような目的がある場合、それが最も理解しやすく、分解の良い基礎になると思います。
これを上記の例に当てはめると、入力、処理、または出力のメンテナンスが必要な場合にどこを見ればよいかは明らかです。それぞれに明確な目的があるため、明確なクラスから始めます。（しかし、私はここで大声で考えて、自分でそれを明確にしようとしています。）
質問は次のとおりです。分解の利点は何ですか?クラスを分解する必要があることを示すものは何ですか?