クラスの数を増やすとコードが複雑になりますか？
質問を説明するために、同じ問題を解決する同等のスキルを持つ2人のプログラマーがいるとしましょう。判明したコードのコード行はほぼ同じですが、あるプログラマーが5つのクラスを使用し、別のプログラマーが20のクラスを使用しています。
コードの両方のセットは、コードレビューで1分あたり同等のwtfsを取得します。これは、コードを追跡するのが難しくなく、愚かなことを何もしないことを意味します。
20クラスのコードは、5を使用するコードよりも複雑ですか？
Cohesion と Coupling は2つの関連する用語ですが、それらの矛盾する性質のため、可能な固定の答えはありません。
凝集
凝集度は、クラスのメソッドがどれだけ密接に連携して機能しているかを示す尺度です。凝集度が高い場合、ほとんどのメソッドは同様のことを担当しますが、凝集度が低い場合、メソッドは多かれ少なかれ独立したことを行います。これは 単一の責任の原則 （SRP）とわずかに関連しており、高い凝集性を目指す必要があることを示しています。
カップリング
結合とは対照的に、カップリングはモジュール/クラス間の相互依存性を指します。高い結合がある場合、これはモジュールが互いに多く相互作用することを意味しますが、低い結合は相互作用が少ないこと、つまり小さなインターフェースであることを意味します。繰り返しますが、低結合の方が優れていることは簡単にわかります。
矛盾
高凝集性と低結合の両方を実現する際の問題は、コードを変更して一方を改善すると、もう一方が減少することを意味します。
簡単な例として、すべての機能が単一のクラスに含まれていると考えてください。これは、結合が非常に低いことを意味します。これは良いことです。ただし、もちろん、クラスのメソッドはすべて異なる処理を実行する必要があるため、凝集度も非常に低くなります。
もう一方の極端な例として、物事を非常に多くのクラスに分割することを検討してください。各クラスには1つの小さなメソッドしか含まれていません。つまり、非常に高い凝集性があり、これもまた良いことですが、実際の作業を行うには、これらのメソッドが他の多くのクラスにアクセスする必要があります。これらの依存関係は、非常に高い結合も得られることを意味しますが、これも良くありません。
トレード・オフ
基本的に、トレードオフが発生します。つまり、結合に焦点を合わせると、結合が失われます。結合に焦点を合わせると、結束が失われます。そのトレードオフスケールのどこに行くべきかについて適切な選択を行うには、結合と凝集自体は不十分な基準です。代わりに、コード品質の他の基準を調べて、それらがどこにつながるかを確認する必要があります。
たとえば、SRPはあなたに良い結束を与え、これを唯一の真実として主張する人々がそこにいますが、もちろん、SRPに非常に厳密に従うと、多くのクラスと高い結合になります。時々、そのすべてのカップリングがあなたに多くのトラブルを与えていることに気付くかもしれません。そのような場合、SRPに違反することによって、結合を犠牲にして結合を減らす価値があることを正当化することができます（または、その単一の責任が何であるかを再解釈するとしましょう）。
ベストプラクティスアプローチとして、SRPは節約策だと思います。一般に、1つのクラス（凝集度）にローカライズされた問題を処理する方が簡単であるという理由だけで、高い結合度は低い凝集度よりも問題があります。したがって、SRPに従うと、トレードオフスケールの低結合端に向かって進みます。これは、少なくとも開始するのに適したポイントです。
私は通常、テーブルごとに1つのクラスに加えて、列挙されたフィールドに必要な数の列挙型に加えて、データサービス、ユーザーコントロール、およびあらゆる種類のものを持っています。私が得る唯一のWTFはユーザーからのものですが、速度は分単位ではなく時間単位で測定されます。
言語の詳細についての議論がないので、私はC＃で行うことによってのみ進むことができます。私は通常、再現性の高いデザインパターンを作成しようとします。これにより、あるクラスを見ている人が他のクラスと似たようなものを見つけることができます。デザインルールを考えると、「数を減らす」ことができるかどうかはわかりません。