今感じているのは「時期尚早の最適化」と呼ばれています。決して起こらないかもしれない問題を解決することへの恐れ/衝動。
誰もが使用するため、関連するすべてのコードが完全に最適化されているため、一般的にクラスの読み込みは遅くありません。
また、クラスの読み込みにテストの実行ごとに数秒かかる場合(=テストごとではなく、実行全体)、テストは通常はるかに長く実行されるため、問題にはなりません(間違った場合は桁違いに長くなります)。
それが最後の最悪の問題であるメンテナンスを残します。記述されたコードの各行は、コードを保守するときに少なくとも無視する必要がある行です。コードを無視するだけでも手間がかかります。したがって、コードは少ない方が常に優れています。
ただし、ここには下限があります。必要なすべての機能をエンコードするには、最小限のコードが必要です。また、必要な機能の絶対最小値に到達しようとすると、多くの労力がかかるため、ほとんどのコードは(ある程度)近づくだけです。
残念ながら、それでも全体像ではありません。適切に記述されたコードがある場合は、それを確認する必要はありません。問題なく機能します。したがって、適切に記述されたコードの保守コストは、たとえば、コンパクトで高速だが理解できないコードよりもはるかに低くなります。
つまり、理解しやすいコードの方が安いということです。つまり、それを独立したビットに分割すると、より安価になります。それは、 OOPの欠陥のために、クラスの爆発につながります。
残念ながら、私たちの知力は限られています。これは、機能があまりにも多くの場所に分散していると、全体像を把握するのが難しくなることを意味します。これは、コードが正確に適切な場所でカットされていない場合(そしてほとんどの場合そうではない場合)に加えて、長期間にわたって完璧なコードを作成できない(品質が変化する)という事実によってさらに悪化します。
結論:クラスが多すぎたり少なすぎたりする可能性があります。外から見分ける方法はありません。それはあなた/あなたのチームがどれだけ優れているか、あなたの問題がどれほど複雑であるか、プロジェクトがどれほど大きいかなどに依存します。良い指標はあなたのバグデータベースと経験における未解決のバグの数です。