関数を「準備」と「実行」の半分に分割するための用語はありますか？
古いコードを再検討していますが、メインロジックが1つのメソッドに含まれていることに気付きました。これは、私が望むよりも長い（〜60行）。だから私はそれを分割し、そうするための自然な継ぎ目があります：前半はUIオブジェクトからパラメーターを収集し、それらを検証し、必要に応じてファイルの上書きを確認し、プロシージャが開始したことをログに記録します。後半は実際の肉です。ファイルを開き、サービスに接続し、データを記録します。 2番目のメソッドはインターフェイスに依存せず、パラメーターを受け入れるだけなので、これはうまく機能します。
しかし、私はnameこれらの2つの半分をどのように扱うかについては明確ではありません。私が思いついた最高のものはGatherParameters()とRecordData()です。これには共通の名前があるはずだと思います。入力を収集して精査するメソッドと、それらのパラメーターを受け入れて（そして信頼して）実行を続けるメソッドです。
明確にするために、私はこのタイプのリファクタリングが何と呼ばれるか（「抽出」と私は推測します）ではなく、「Prep/Test」メソッドと「Do」メソッドの結果のコードパターンについて質問しています。
ちなみに、メソッドはSalesforceでユーザーが選択したテーブルからデータを取得するため、RecordData()の漠然とした名前がこの場合に適用されます。コンパイル時にどのタイプのデータが記録されるかは不明です。
ここで言及しているのは特定のデザインパターンではなく、「懸念の分離」と呼ばれるより一般的なソフトウェア開発の原則です。これらの懸念をUIロジック、サービスの使用、データ処理などのより具体的な領域に限定すると、ほぼMVC/MVPの世界になり、実際にパターンと見なされる可能性があります。
一方、インターフェースにとらわれない設計では、懸念の分離の原則が強調されます。懸念が分離され、それらのインターフェースが明確に定義されているため、最終的に依存関係が最小限になり、再利用性の高いソフトウェアになります。小さな問題に対して個別のソリューションを定義すると、ソリューションが複数の異なる問題を同時にカバーする場合よりも、他の大きな問題に小さな問題全体が含まれる可能性が高くなることは容易に想像できます。