The Object Oriented Concepts Surveyに充填しながらは、（ソフトウェア設計上の実際のデータをいくつかの学術研究者を提供するために）、私はこの質問に出くわしました：あなたのクラスで許可する最大限のメソッドの制限はいくらですか？
あなたのクラスで許可した最大の方法の限界Nは何ですか？
調査では、あなたは私のアプリケーションを設計し、この背後にある理由があるのだろうしながら、私は正直、このような制限について考えたことがありません。この制限N.
に達すると、あなたのクラスをリファクタリングかどうかを尋ねるになります。なぜ私はクラスの機能に非常に依存している任意の数字を自分自身に課したいのですか？
最大Nを制限する必要はありません。しかし、あなたは「高結束」の原則に従わなければなりません。そして、何でもできるクラスを作成しないでください。
あなたは心配する必要があるいくつかのNがあると思います。しかし、それはクラスそのものとその主な目的に本当に依存しています。
我々は上のルールをベースにすることができますマジックナンバーがありますという考えは、その願望感覚を上回る宇宙に秩序を課すものとは通常squeamishnessです。
つまり、クラスに20以上のメソッドがある場合、あまりにも多くのことを行い、SRPに違反している可能性があります。
私はどちらかの事上の任意の制限を入れていないだろうが、私はクラス一度どこかで10-20 publicメソッドで、私はそのクラスが何をしているかの深刻な表情を取ると思い範囲よりも多くを持っていると言うでしょう。私のJ2EE時代には、Enterprise Java Melonと呼ばれました。
個々のメソッドの長さにも同じルールが適用されます。私は1つまたは2つのメソッドしかないクラスを見たことがありますが、それぞれのメソッドは数百行のコードでした。他の人がそこに一般的に指摘しているよう
「新しい回答」のダイアログが現れたとき、私は同じことを書いていました。 +1 – jdmichal
+1、小さく集中したクラスは良いですが、メソッドの数やサイズの任意の制限は最終的には有用ではありません。 –
は、私が言うよその時点で方法のいくつかの任意の数ではありません「それはあまりにも多くの方法があります！」オブジェクトが何百もの行にまたがるモノリシックなdo-everythingメソッドを持っている場合など、逆も同様に悪いことがあります。私は私が前に見ていないソースファイルを開き、より10-20方法を見れば、私はおそらくそれが何らかの方法でリファクタリングすることができないかどうかを確認するために、それをスキャンし、言われていること
。
私はクラスを1つの責任にまで分け始めて以来、私は通常疑わしい場所に近づくことはありません。
また、よく設計されたクラスには30のメソッドがあり、設計が不適切なものは3つあります（Umm、30はそれを押していますが、これは必ずしも良いメトリックではありませんカウントKLOC）のような
あなたのフレームワーク/言語はあまりにもビジネスロジックなしのメソッドの多くを必要とすることができます。
それらのビジネスロジックで非自明な方法の数をカウントすることは面白いかもしれません - I'dは約4または5が適切であろうと言います。
私は、ソースコードを見ているときにJDKクラスが実際にどれほど多くのメソッドを持っているのか驚いていましたが、とても壊れていて、小さくて簡単に読めるので、 20。
私はこれに原則として同意しますが、20はあまりにも低いです。 – DJClayworth