クラスメソッドの数の制限は何ですか？
私が読んださまざまなデザインブックでは、クラスに必要なメソッドの数に大きな重点が置かれることがあります（OO言語、Javaまたは多くの場合、これらの本で報告されている例は非常に簡潔で単純ですが、「深刻な」または複雑なケースをカバーすることはめったにありません。
ただし、範囲は5〜8のようです
プロジェクトで、属性として属性を使用してクラス「Note」を開発しました：Title、Desctiption、CreateDateなど。
次に、getRelations（ノートが別のドキュメントに割り当てられている場合）、getExpiryDateなどの基本的なメソッドがあります。
ただし、アプリケーションの開発を進めるには、より多くの機能が必要であり、したがって、より多くのメソッドが必要でした。
クラスが持つメソッドが少ないほど、疎結合になります。これは確かに、モジュール性と再利用性の点で優れた利点であり、編集も簡単です。
ところで、私たちのコンテキストでサブクラスを作成する必要がなく（または意味がなく）、必要なすべての関数がそのクラスに関連している場合、さらにいくつのメソッドをアタッチできますか？
15を超えるメソッドを使用する場合は、少し再設計が必要になる可能性があることに同意します。
しかし、その場合でも、メソッドまたは継承の一部を削除することがオプションではない場合、どちらが適切な方法でしょうか？
必要な数だけメソッドを用意してください。可能であれば、パブリックメソッドの数を5〜8のルールに抑えるようにします。正直なところ、ほとんどの人は反対の問題を抱えており、クレイジーなスーパーメソッドを使用する必要があります。プライベートヘルパーメソッドがいくつあるかは関係ありません。実際、Javaで8つ以下のメソッドに留まった場合、コンストラクター、toString、および3つのプロパティのゲッター/セッターのみを含むクラスで制限に達する可能性があります...厳密に言えば、堅牢なクラスではありません。重要なのは、クラスのメソッドの数を気にしないことです。クラスが無関係の懸念事項を引き受けないこと、およびメソッドを理解しやすい適切なパブリックインターフェイスがあることを確認してください。
答えは非常に簡単です。責任に属するクラスにすべてを入れますが、責任を割り当てるときは注意してください。
大きなクラスは、異なる責任を持つ小さなクラスの複合である場合があります。
一般に、クラスがその使用法やメンテナンスで扱いづらくなったら、私は責任をより小さなクラスに分割しようとします。 500行を超えるクラスはめったにありません。私の最大のクラスにはおよそ1.5kの場所があります。
「クラスにはn個からm個のメソッドが必要です」のような一般的な規則を単に述べることはできません。
（OO設計では）メソッドが非常に多いだけの理由はありません。メソッド数が少ないクラスの方がデカップリングが優れていることも事実ではありません。
たとえば、Java.lang.Stringクラスを見てください。文字列でできることはたくさんあるので、たくさんのメソッドがあります。それにもかかわらず、強く結合されていません。
15のようなマジックナンバーでデザインの良し悪しを区別できるのはなぜでしょうか。いいえ、簡単ではありません。
PMDでは、 TooManyMethodsルール のデフォルトの動作は、10以上のメソッドを持つクラスを潜在的なエラーとして識別し、フラグを立てることです。ただし、これは任意の数値です。構成で簡単に変更できます。この数値が何であるかに関係なく、開発者がクラスを調べて問題があるかどうかを確認するのは単なるフラグであり、問題があるかどうかではありません。
もう少し具体的なものは 7プラス/マイナス2ルール かもしれません。これは、人間の心が5〜9の「オブジェクト」を記憶に保持し、理解できることを示しています。特定のクラスを読み取る場合、オブジェクトはおそらくそのクラスを構成するメソッドとフィールドです。ただし、アクセサー、ミューテーター、標準操作（toString()、hashCode()、equals()（Javaの場合）。
最も適切な測定は、 ファンインおよびファンアウト と カップリング および 凝集 の議論です。 単一の責任の原則 および 懸念の分離 を適用する必要があります-クラスは1つのことと1つのことだけを行うか、または表す必要があります。これらは、設計または実装を評価するときに、メソッドの最大数/最小数に数値を割り当てようとするよりもはるかに優れています。