メソッドを作成するときは、そのメソッド内のコードブロックをプライベートメソッドに抽出しようとします。
たとえば、入力パラメーターの1つを変換する必要がある場合は、パラメーター値を受け入れて変換された値を返すプライベートメソッドを作成します。私はこのプライベートメソッドを「main」メソッドの本体から呼び出します。本質的には、変換操作がプライベートメソッド内にあるものはすべてカプセル化し、メソッドに適切な名前を付けようとします。
私は、人々がこの一般的なアプローチが良い考えであると考えるかどうかについての答えを本当に探しています。他の開発者からのフィードバックはまちまちで、すべてのコードを1つのメソッド内に保持することを好む人もいます。私は、小さなプライベートメソッドがこれらの単一のタスクをカプセル化すると主張し、コードが1つのメソッドに保持されている場合、クラスはよりクリーンに保たれると主張します。
コミュニティから、より良い設計を反映している、またはOOPの原則に沿っていると感じるアプローチについていくつかの回答を得るのは素晴らしいことです。
私は一般的に多くの理由で同じことをします：
私は、一般的な経験則として、何が起こっているのかを説明するためにメソッド本体にコメントを入れなければならないのは匂いであり、それをより小さな断片にリファクタリングできることを意味します。
HTH
簡単に言えば、それは一般的に良い考えです。
詳細については、DeveloperWorksのNealFordのComposedMethodの記事を参照してください。この記事では、ニールがプライベートメソッドにリファクタリングして、再利用に適したコードの領域を分離する方法を説明します。
この演習の本当に重要な利点は、再利用可能なコードを収集できることです。リスト1のコードを見ると、再利用可能なアセットはありません。コードの山が表示されます。オリオメソッドを分解することで、再利用可能なアセットを見つけます。しかし、利点は再利用を超えています。また、アプリケーションの永続性を処理するための単純なフレームワークの基盤を作成しました。データベースからエンティティを収集するための別の単純な境界クラスを作成するときが来たら、それを行うのに役立つコードがすでにあります。これは、象牙の塔にフレームワークを構築するのではなく、フレームワークを抽出することの本質です。
一般的には、（自分自身を繰り返さないために）より多くの場所で必要なコードをメソッドに入れる必要があります。
メソッドが非常に長い場合は、コードを他のメソッドに配置することも理にかなっています。その場合は、コードをいくつかのメソッドに分割することも理にかなっています。