The Object Oriented Concepts Survey (一部の学術研究者にソフトウェア設計に関する実際のデータを提供するため) に記入しているときに、次の質問に出くわしました。
クラスで許可する最大メソッドの制限 N はいくつですか?
この制限 N に達したら、クラスをリファクタリングするかどうかを調査し続けます。
正直なところ、アプリケーションを設計する際にそのような制限について考えたことはなく、その背後にある理由が何であるか疑問に思っています。おそらくクラスの機能に大きく依存している任意の数を自分自身に課したいのはなぜですか?
最大の N を制限する必要はありません。ただし、「高結束」の原則に従わなければなりません。また、何でもできるクラスを作成しないでください。
N の後に心配し始める必要があると思います。しかし、それは実際にはクラス自体とその主な目的に依存します。
ルールの基礎となる魔法の数があるという考えは、宇宙に秩序を課したいという願望が自分の感覚を上回っている人々の通常のきしみです.
とはいえ、クラスに 20 個以上のメソッドがある場合は、実行しすぎてSRPに違反している可能性が高くなります。
恣意的な制限もありませんが、クラスに 10 ～ 20 個のパブリック メソッドの範囲のどこかを超えるクラスがある場合は、そのクラスが何をしているかを真剣に検討します。私の J2EE 時代には、私たちはそれらを Enterprise Java Melons と呼んでいました。
個々のメソッドの長さにも同じ規則が適用されます。1 つまたは 2 つのメソッドしか持たないクラスを見てきましたが、それらのメソッドはそれぞれ数百行のコードでした。
クラスを1つの責任に分解し始めてから、通常、疑わしい場所には近づきません。
また、適切に設計されたクラスには 30 個のメソッドがあり、設計が不十分なクラスには 3 個のメソッドがある場合があります (うーん、30 はそれを押し上げていますが、要点は、これは必ずしも良いメトリックではなく、kloc を数えるようなものです)。
あなたのフレームワーク/言語は、ビジネスロジックなしでも多くのメソッドを必要とする場合があります.
ビジネス ロジックを含む重要なメソッドの数を数えてみると面白いかもしれません。4 つまたは 5 つくらいが適切だと思います。
ソースコードを見ていると、JDK クラスに実際に含まれているメソッドの数に驚きましたが、それらは非常によく壊れており、非常に小さく、簡単に読み取れるので、20 個あってもまったく問題ありませんでした。
他の人が指摘したように、一般的に任意の数のメソッドはありません。その時点で「メソッドが多すぎます!」と言うでしょう。オブジェクトが何百行にもわたるモノリシックな do-everything メソッドを持っている場合など、逆の場合も同様に悪い場合があります。
そうは言っても、以前に見たことのないソース ファイルを開いて 10 ～ 20 を超えるメソッドが表示された場合は、おそらくそれをスキャンして、何らかの方法でリファクタリングできないかどうかを確認します。