目立った違いはありません。このような極端なマイクロ最適化について考える前に、約 3000 LOC のクラスで非常に危険にさらされている保守性について考える必要があります。
最初に、正しく保守しやすいコードを作成してください。実際にパフォーマンスの問題が発生した場合にのみ、最適化に関する決定を下す前に、まずアプリケーションのプロファイルを作成する必要があります。通常、パフォーマンスのボトルネックは別の場所で見つかります (並列化の欠如、不適切なアルゴリズムなど)。
いいえ、1 つの大きなクラスを使用してもパフォーマンスに影響はありません。大きなクラスを小さなクラスに分割すると、リダイレクトが増えるため、パフォーマンスが低下することさえあります。ただし、ほとんどの場合、影響は無視できます。
クラスを小さな部分に分割する目的は、パフォーマンスを向上させることではなく、コードの読み取り、変更、および保守を容易にすることです。しかし、これだけでも、それを行う十分な理由があります。
適切に設計された少数のクラスを 1 つのソース ファイルに追加するかどうかを決定する場合、パフォーマンスに関する考慮事項は最後の懸念事項です。さらに考えてみましょう:
続けることもできますが、大きな単一ソース ファイルの考え方は、VB/手続き型プログラミングの時代にさかのぼるようです。最近では、メソッドの循環的複雑度が 15 を超えていて、クラスに数百行を超える行があると、私は不安になり始めています。
通常、これらの 10,000 行の巨大なコードの 1 つをリファクタリングすると、新しいクラスのコード行の合計は元のコード行の 40% になることになります。より多くのクラスと分解 (妥当な範囲内) は、より少ないコードにつながります。最初は直感に反しますが、実際に機能します。
本当の問題は、パフォーマンスのオーバーヘッドではありません。オーバーヘッドは保守性と再利用にあります。オブジェクト指向設計のSOLID原則は難しいかもしれませんが、その多くは、クラスが小さいほど優れていることを意味します。特に、単一責任の原則、オープン/クローズの原則、リスコフの置換原則を見て、実際に考えてみると、それらはすべて、間接的ではありますが、小さなクラスの方が優れていることをほとんど暗示しています。
このようなものを「入手」するのは簡単ではありません。OO 言語でプログラミングをしていて SOLID を見ていて、突然それがとても理にかなっています。しかし、それらの電球が点灯するまで、それは少しあいまいに見えるかもしれません.
はるかに簡単なことに、いくつかのクラスを持ち、クラスごとに 1 つのファイルを持ち、各クラスが 1 つのジョブを持ち、動作を説明するために適切に名前が付けられた各クラスは、3,000 の長いページよりも純粋な健全性の観点から管理しやすい必要があります。行。
次に、3,000 行のクラスの一部がプログラムの別の部分で役立つかどうかを検討してください。その機能を専用クラスに配置することは、再利用のためにカプセル化する優れた方法です。
本質的に、私が書いているように、とにかく SOLID の側面をからかっているだけであることがわかりました。これについては、馬の口から直接読むのがおそらく最善でしょう。
パフォーマンスの問題があるとは言いませんが、読みやすさの問題を維持します。1 つの巨大なクラスを操作するよりも、それぞれがその目的を実行するより多くのクラスを変更する方がはるかに簡単です。それはばかげている。そうすることで、すべての OOP 原則を破っています。
したがって、今まで複数の小さなクラスを作成していないので、問題はありません
まさに私が SO で何度も警告してきたケースです...人々は時期尚早の最適化を恐れていますが、「問題が発生したら後で修正します」のような考えで悪いコードを書くことを恐れていません。 "。一言言わせてください - 3000+ LOC クラスは、パフォーマンスへの影響があったとしても、すでに問題になっています。
クラスの使用方法とインスタンス化の頻度によって異なります。コントラクト サービス クラスなど、クラスが 1 回インスタンス化されると、一般的なパフォーマンス オーバーヘッドはそれほど大きくありません。
クラスが頻繁にインスタンス化される場合、パフォーマンスが低下する可能性があります。
ただし、この場合、パフォーマンスについてではなく、デザインについて考えてください。サポートとさらなる開発とテスト容易性について考えたほうがよいでしょう。3K LOC のクラスは巨大で、通常はアンチパターンの本です。このようなクラスはコードの重複とバグにつながり、さらなる開発は苦痛であり、すでに修正されたバグが何度も発生する原因となり、コードは脆弱です。
したがって、クラスは間違いなくリファクタリングする必要があります。