これは良いパターンですか？長い関数を一連のラムダに置き換えますか？

最近、次のような状況に遭遇しました。

class A{
public:
    void calculate(T inputs);
}

まず、A物理世界のオブジェクトを表します。これは、クラスを分割しないことの強力な議論です。今、calculate()非常に長く複雑な機能であることが判明しました。私は3つの可能な構造を知覚します：

• テキストの壁としてそれを書く-利点-すべての情報が一箇所にある
• privateクラスでユーティリティ関数を記述し、それらをcalculateボディで使用する-欠点-クラスの残りの部分は、これらのメソッドを知らない/気遣わない/理解しない

• calculate次のように書きます：

  void A::calculate(T inputs){    
      auto lambda1 = () [] {};    
      auto lambda2 = () [] {};    
      auto lambda3 = () [] {};
  
      lambda1(inputs.first_logical_chunk);
      lambda2(inputs.second_logical_chunk);
      lambda3(inputs.third_logical_chunk);
  }

これは良いプラクティスか悪いプラクティスか？このアプローチは問題を明らかにしますか？全体として、再び同じ状況に直面したとき、これを良いアプローチと考えるべきですか？

編集：

class A{
    ...
public:
    // Reconfiguration of the algorithm.
    void set_colour(double colour);
    void set_density(double density);
    void set_predelay(unsigned long microseconds);
    void set_reverb_time(double reverb_time, double room_size);
    void set_drywet(double left, double right);
    void set_room_size(double value);;

private:
    // Sub-model objects.
    ...
}

これらすべての方法：

• 値を得る
• 状態を使用せずに、他の値を計算します
• いくつかの「サブモデルオブジェクト」を呼び出して、状態を変更します。

set_room_size()これらのメソッドは、要求された値をサブオブジェクトに渡すだけであることがわかります。set_room_size()一方、あいまいな式の画面をいくつか表示し、（2）サブオブジェクトのセッターを呼び出す画面の半分を実行して、取得したさまざまな結果を適用します。したがって、関数を2つのラムダに分割し、関数の最後で呼び出します。もっと論理的なチャンクに分割できたら、より多くのラムダを分離できたでしょう。

とにかく、現在の質問の目標は、その考え方が持続するべきか、それともせいぜい価値（読みやすさ、保守性、デバッグ能力など）を追加しないかを決定することです。

いいえ、これは一般的に良いパターンではありません

あなたがしているのは、ラムダを使用して関数をより小さな関数に分割することです。ただし、関数を分割するためのはるかに優れたツール、関数があります。

ラムダの仕事は、あなたが見てきたように、彼らは意味ずっとずっとずっとずっとずっと単純にローカルビットに機能を分割以上。ラムダは：

• 閉鎖。ラムダ内の外部スコープで変数を使用できます。これは非常に強力で非常に複雑です。
• 再割り当て。あなたの例では割り当てが難しくなりますが、コードはいつでも関数を交換できるという考えに常に注意を払う必要があります。
• 一流の機能。ラムダ関数を別の関数に渡し、「関数型プログラミング」として知られていることを実行できます。

ラムダをミックスに取り込むと、次にコードを見る開発者は、コードがどのように機能するかを確認するための準備として、これらすべてのルールを直ちに精神的にロードする必要があります。彼らはあなたがあなたがそのすべての機能を使うつもりがないことを知りません。これは、代替案と比較して非常に高価です。

バックホーを使ってガーデニングをするようなものです。今年の花のために小さな穴を掘るためだけにそれを使用していることを知っていますが、隣人は緊張します。

あなたがしているのは、ソースコードを視覚的にグループ化することだけだと考えてください。コンパイラは、実際にラムダを使用してカリー化したことを気にしません。実際、オプティマイザーは、コンパイル時に行ったすべての操作をすぐに取り消すことを期待しています。あなたは純粋に次の読者を対象にしています（方法論に異論があるとしても、そうしてくれてありがとう！コードは書かれているよりもはるかに頻繁に読まれています！）。あなたがしているのは、機能をグループ化することだけです。

• ソースコードのストリーム内にローカルに配置された関数も、ラムダを呼び出さずに同様に実行します。繰り返しますが、重要なのは、読者がそれを読むことができるということです。
• 関数の上部にある「この関数を3つの部分に分割している」というコメントの後に、// ------------------各部分の間に長い長い行が続きます。
• 計算の各部分を独自のスコープに入れることもできます。これには、部品間で変数の共有がないことを疑う余地なくすぐに証明するというボーナスがあります。

編集：サンプルコードで編集を見ることから、コメントが示唆する境界を強制するための括弧を使用して、最もクリーンなコメント表記に傾倒しています。ただし、機能のいずれかが他の機能で再利用可能な場合は、代わりに機能を使用することをお勧めします

void A::set_room_size(double value)
{
    {
        // Part 1: {description of part 1}
        ...
    }
    // ------------------------
    {
        // Part 2: {description of part 2}
        ...
    }
    // ------------------------
    {
        // Part 3: {description of part 3}
        ...
    }
}

あなたは間違った仮定をしたと思います：

まず、Aは物理世界のオブジェクトを表します。これは、クラスを分割しないことの強力な議論です。

私はこれに同意しません。たとえば、車を表すクラスがある場合、タイヤを表す小さなクラスが必ず必要になるため、確実に分割する必要があります。

この関数をより小さなプライベート関数に分割する必要があります。それが本当にクラスの他の部分から分離されているように見える場合、それはクラスが分離されるべきであるというサインかもしれません。もちろん、明確な例を使わずに伝えるのは難しいです。

この場合、ラムダ関数を使用する利点は実際にはわかりません。ラムダ関数を使用すると、コードが実際にきれいにならないからです。関数型プログラミングを支援するために作成されましたが、これはそうではありません。

あなたが書いたものは、Javascriptスタイルのネストされた関数オブジェクトに少し似ています。これもまた、それらが密接に関係していることを示しています。あなたは彼らのために別個のクラスを作るべきではないことを確信していますか？

要約すると、これが良いパターンだとは思いません。

更新

この機能を意味のあるクラスにカプセル化する方法が見つからない場合は、クラスのメンバーではないファイルスコープのヘルパー関数を作成できます。結局、これはC ++であり、オブジェクト指向設計は必須ではありません。