私がすでに学んだ限りでは、長い一連の操作を含むメソッドは悪いことと見なされており、再設計する必要があります。それ以上に、メソッドは画面よりも大きくすべきではないという意見を聞きました (つまり、スクロールする必要なく、すべてのメソッド コードが IDE 画面に一度に表示されるべきです)。
これに関する一般的なルールはありますか？たとえば、「メソッドの長さが 15 行を超える場合は、リファクタリングする必要があります」? もしそうなら、どのようにリファクタリングしますか？抽出方法を使用するだけですか？
それはあなたが誰に尋ねるかによります。 Robert Martinは、2 つのルールがあることを教えてくれます。
行数の観点から考えないでください。行数は恣意的で重要ではないメトリックです。メソッドが論理的に何をするかという観点から考えてみてください。最良のルールは次のとおりです。
または、より良い方法で言えば：
(まだここでボブおじさんをチャネリングしていますが、最近はクリーンコードをかなり強く打っています。)
これを次のような他の論理ルールと組み合わせます。
そして、一般に、非常に小さなメソッドになってしまいます。ただし、例外もあります。多くの場合、「1 つのこと」は 1 行、場合によっては 2 行または 3 行のコードで表現されます。しかし、それはシンプルで表現力豊かなコードであり、その「1 つのこと」が何であるかは明らかです。(もちろん、メソッドの名前は、その 1 つのことを明確に反映する必要があります。)
ただし、「1 つのこと」がより長い一連のステップである場合もあります。ドメイン内に 1 つのアトミック プロセスをカプセル化したメソッドがあるかもしれませんが、そのプロセスはたまたま 12 以上のステップで構成されています。各ステップは独自の「1 つのこと」であり、内部的には他のメソッドなどで他の「1 つのこと」を持っている可能性があります。
個々のメソッドはそれぞれ「1 つのこと」を行います。しかし、小さなステップをより大きなアトミック プロセスに集約する高レベルのカプセル化メソッドは、「1 つのこと」が多くの小さな「1 つのこと」で構成されているため、少し長くなります。まれですが、起こります。そして、それが発生したときの通常の結果は、一連のメソッド呼び出しに過ぎない 1 つのメソッドです。(これが長いメソッドの言い訳であると言っているわけではありません。コードのロジックを注意深く調べて、より大きなメソッドのリファクタリングが実際に意味があるかどうかを判断してください。)
このより大きなカプセル化方法は、多くの場合、トランザクション スクリプト パターンをビジネス ロジックに適用した結果です。ビジネス ロジック内のマルチステップ プロセスで構成される、1 つの要求に応答する 1 つのステップがあります。
メソッドは小さくする必要があります。それらはそれよりもさらに小さくする必要があります。そうでない場合は、詳細を調べて理由を判断してください。複数のレベルのインデントがある場合、それは通常、リファクタリングが必要であることを示しています。入力からのチェック アンド バランスが複数ある場合は、何らかのリファクタリングが必要になる可能性があります。メソッドが複数のことを行っている場合、または変更する理由が複数ある場合は、間違いなくリファクタリングする必要があります。
通常、大きな関数を小さな関数に分割することは非常に良い考えです。
それらがうまく設計されていて、何が起こっているのかを理解するのが簡単であれば問題ありません。しかし、関数が大きいほど、それを行うのは難しくなります。機能をシンプルに保つことで、後で問題を簡単に追跡できるようになります。
初期のプログラマーは、メソッドの長さをわずか 10 行のコードに制限していました。彼らの方法がそれ以上長くなった場合、彼らはそれを分割しました。これは時代遅れのプログラミング スタイルであり、現在では広く使用されていません。ほとんどの専門家は、方法が理にかなっている限り、方法は可能であることに同意します。(つまり、論理的なブレークポイントがない限り、それらは分割されるべきではないことを意味します)
個人的には、より短い方法を目指しています。しかし、そうは言っても、明らかな論理的な区切り点がない限り、長いものを分割することはしません。これの唯一の理由は、コードを読みやすくデバッグしやすくするためです。特にメソッド名がわかりやすい場合。