多くの小さなメソッド (または関数) を記述するのと、それらの小さなプロセスのロジック/コードを小さなメソッドを呼び出した場所に直接記述するのとではどちらがよいでしょうか? 当面は 1 つの場所からしか呼び出されない場合でも、コードを小さな関数に分割するのはどうですか?
人の選択がいくつかの基準に依存する場合、それらは何ですか。プログラマーはどのように適切な判断を下す必要がありますか?
回答が多くの言語に一般的に適用できることを願っていますが、必要に応じて、特定の言語に固有の回答を提供することもできます。特に、SQL (関数、ルール、ストアド プロシージャ)、Perl、PHP、Javascript、Ruby について考えています。
私は常に、長いメソッドを論理的なチャンクに分割し、それらからより小さなメソッドを作成しようとします。通常、2 つの異なる場所で必要になるまで、数行を別のメソッドに変換することはありませんが、読みやすさを向上させるため、または単独でテストしたい場合にのみ行うことがあります。
Fowler's Refactoringはすべてこのトピックに関するものであり、強くお勧めします。
これは、リファクタリングで使用する便利な経験則です。コードのセクションに、メソッド名に言い換えることができるコメントがある場合は、それを取り出してメソッドにします。
メソッドのサイズは、その循環的複雑度に直接関係しています。
メソッドのサイズを小さく保つ (つまり、大きなメソッドをいくつかの小さなメソッドに分割する) ことの主な利点は次のとおりです。
いつものように、状況によります。メソッドのタスクの名前付けと定義の問題です。すべてのメソッドは、明確に定義された 1 つの (複数ではない) タスクを実行し、それらを完全に実行する必要があります。メソッドの名前は、タスクを示す必要があります。メソッドの名前が DoAandB() の場合、DoA() と DoB() のメソッドを分けたほうがよい場合があります。setupTask、executeTask、FinishTask などのメソッドが必要な場合は、それらを組み合わせると便利な場合があります。
異なるメソッドのマージが役立つ可能性があることを示すいくつかのポイント:
メソッドの分割が役立つ可能性があることを示すいくつかのポイント:
unit-test-argument の説明として: IO を含むいくつかのことを行うメソッドを書きました。IO 部分はテストするのが非常に難しかったので、考えてみました。私の方法は 5 つの論理的で独立したステップを実行し、そのうちの 1 つだけが IO を含むという結論に達しました。そこで、メソッドを 5 つの小さなメソッドに分割しました。そのうちの 4 つは簡単にテストできました。
毎回小さなメソッド。
それらは自己文書化されています（適切な名前が付けられていれば）
彼らは問題を扱いやすい部分に分解します - あなたは KeepingItSimple です。
OO 手法を使用して、より簡単に (そして明らかに) 動作をプラグインできます。大規模なメソッドは、定義上、より手続き型であり、柔軟性が低くなります。
それらは単体テスト可能です。これはキラーです。大量のタスクを実行する巨大なメソッドを単体テストすることはできません
The Code Complete 本から学んだこと:
お役に立てれば
小さなメソッドがたくさんあると、コードが読みやすくなり、保守やデバッグが容易になることがわかりました。
いくつかのビジネス ロジックを実装する単元を読んでいるときに、プロセスを説明する一連のメソッド呼び出しが表示されると、フローをよりよく理解できます。メソッドの実装方法が気になる場合は、コードを確認できます。
より多くの作業のように感じますが、最終的には時間を節約できます。
何をカプセル化するかを知るには芸術があると思います。誰もが多少の意見の相違を持っています。一言で言えば、各メソッドは、完全なタスクとして記述できる 1 つのことを実行する必要があると言えます。
いくつかの経験則:
私は各関数に 1 つのことを 1 つだけ実行させ、ロジックをネストしすぎないようにしています。コードを適切な名前の関数に分解し始めると、読みやすくなり、実質的に自己文書化されます。
私は通常、関数をより小さな関数に分割し、それぞれが単一のアトミックタスクを実行するようにしますが、その関数が十分に複雑である場合に限ります。
このように、私は単純なタスクのために複数の関数になってしまうことはありません。私が抽出する関数は、あまり達成しようとしないため、通常は他の場所で使用できます。これは、各機能（論理的なアトミックアクションとして）を個別にテストできるため、単体テストにも役立ちます。
メソッドが大きくなるほど、テストと保守が難しくなります。大きなプロセスがアトミックなステップに分解されると、そのプロセスがどのように機能するかを理解しやすくなります。また、これを行うことは、クラスを拡張可能にするための優れた最初のステップです。これらの個々のステップを仮想 (継承用) としてマークしたり、それらを他のオブジェクト (構成) に移動したりして、アプリケーションの動作をカスタマイズしやすくすることができます。
個人的には、より多くのより小さなメソッドを好む方向に大きく傾いていますが、宗教的に最大の行数を目指しているわけではありません。私の主な基準または目標は、コードを DRY に保つことです。複製されたコード ブロックがあるとすぐに (精神的なものであろうと、実際にはテキストによるものであろうと)、それが 2 行または 4 行の長さであっても、そのコードを別のメソッドに乾かします。将来再び使用される可能性が高いと思われる場合は、事前にそうすることがあります。
反対に、ブレークオフ メソッドが小さすぎると、開発者チームのコンテキストでは、チームメイトがあなたのメソッドを知らない可能性が高く、インラインで書くか、または同じことをする彼自身の小さな方法。これは確かに悪い状況です。
また、物事をインラインに保つ方が読みやすいと主張しようとする人もいます。そのため、リーダーは、おそらく複数のファイルにわたってメソッド定義を飛び回る必要がなく、トップダウンで読むことができます。個人的には、スタック トレースの存在により、これはあまり問題にならないと思います。