oop - クラスが長すぎるのはいつですか？

Question

関数が長すぎるのはいつですか？この質問のサブセットだと思います。

クラスが長すぎると判断するためのいくつかの良い指標は何ですか？

外部の請負業者とのプロジェクトの一連のコード受け入れガイドラインを改訂していますが、これまではカバーしていませんでしたが、将来はカバーする必要があることに気付きました。

Answer 1

複数の責任がある場合。

ここでロバートC.マーチンのクリーンコードを引用させてください：

クラスの最初のルールは、それらを小さくする必要があるということです。クラスの2番目のルールは、クラスをそれよりも小さくする必要があるということです。...関数を使用して、物理的な線を数えることでサイズを測定しました。クラスでは、異なる尺度を使用します。私たちは責任を数えます。[第10章、136ページ]

Answer 2

クラスのファンアウトの複雑さ：特定のクラスが依存する他のクラスの数。また、この2乗は、少なくとも関数型プログラムで必要な保守の量を（ファイルベースで）示すために示されています。

循環的複雑度：指定された制限に対して循環的複雑度をチェックします。複雑さは、if、while、do、for、？：、catch、switch、caseステートメント、および演算子&&と||の数によって測定されます。（プラス1）コンストラクター、メソッド、静的初期化子、またはインスタンス初期化子の本体。これは、ソースを通る可能なパスの最小数、したがって必要なテストの数の尺度です。通常、1〜4は良好と見なされ、5〜7は正常、8〜10はリファクタリングを検討し、11以上はリファクタリングを実行します。

Answer 3

17行以内。これ以上でもそれ以下でもありません。したがって、17行未満の場合は、キャリッジリターンでうまくいきます。17を超える場合は、関数内から他の関数​​の呼び出しを開始する必要があります。

例えば：

public function myFunction() {
...
line 17: myFunctionPart2();
}

public function myFunctionPart2() {
...
line 17: myFunctionPart3();
}

等々。

そのかなり標準的なプログラミングの練習。

Answer 4

1つのクラスに1つの責任だけが必要です。それはその長さよりも良い尺度です。したがって、コードを設計するときは、設計のすべてのユニット（タイプまたはクラス）が1つのことだけを担当する必要があります（「1つのこと」が何であれ）。できるだけシンプルにすれば、混乱することはありません。

Answer 5

今では管理が難しくなり、行き詰まってしまうと思うと。

Answer 6

使用中のデザインパターンを無視して、クラスが果たす責任の範囲を検討します。スコープが大きすぎる場合は、特定の責任に分割するか、抽象化するか、より一般的にする必要があります。

私は実際には行数を意味のあるメトリックとは見なしません。