Это хороший шаблон: заменить длинную функцию серией лямбд?

Я недавно столкнулся со следующей ситуацией.

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

Во-первых, Aпредставляет объект в физическом мире, что является веским аргументом для того, чтобы не разделять класс. Теперь calculate()оказывается довольно долгая и сложная функция. Я воспринимаю три возможных структуры для этого:

• напишите это как стену текста - преимущества - вся информация в одном месте
• писать 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) выполняет половину экрана вызова установщиков подобъектов, чтобы применить различные полученные результаты. Поэтому я разделил функцию на две лямбды и вызываю их в конце функции. Если бы мне удалось разбить его на более логичные куски, я бы выделил больше лямбд.

Независимо от того, цель текущего вопроса состоит в том, чтобы определить, должен ли такой образ мышления сохраняться, или это в лучшем случае не добавляет ценности (удобочитаемость, ремонтопригодность, способность к отладке и т. Д.).

Нет, это не очень хорошая модель

То, что вы делаете, разбиваете функцию на более мелкие функции, используя лямбду. Однако есть гораздо лучший инструмент для разделения функций: функции.

Как вы уже видели, лямбды работают, но они значат намного больше, чем просто разбиение функции на локальные биты. Лямбды делают:

• Затворы. Вы можете использовать переменные во внешней области видимости внутри лямбды. Это очень мощно и очень сложно.
• Перераспределение. В то время как ваш пример затрудняет выполнение присваивания, всегда нужно обращать внимание на идею, что код может поменять местами функции в любое время.
• Первоклассные функции. Вы можете передать лямбда-функцию другой функции, выполнив что-то, известное как «функциональное программирование».

В тот момент, когда вы добавляете лямбда-выражения в смесь, следующий разработчик, который должен взглянуть на код, должен немедленно мысленно загрузить все эти правила, чтобы увидеть, как работает ваш код. Они не знают, что вы не собираетесь использовать всю эту функциональность. Это очень дорого по сравнению с альтернативами.

Это все равно, что использовать ботинок для садоводства. Вы знаете, что вы используете его только для рытья маленьких ям для цветов этого года, но соседи будут нервничать.

Учтите, что все, что вы делаете - визуально группируете свой исходный код. Компилятору на самом деле все равно, что вы каррилируете с лямбдами. На самом деле, я ожидаю, что оптимизатор немедленно отменит все, что вы только что сделали, когда он компилируется. Вы просто угощаете следующего читателя (спасибо за это, даже если мы не согласны с методологией! Код читается гораздо чаще, чем пишется!). Все, что вы делаете, это группируете функциональность.

• Функции, размещенные локально в потоке исходного кода, будут работать точно так же, не вызывая лямбду. Опять же, все, что имеет значение, - это то, что читатель может это прочитать
• Комментарии вверху функции говорят: «мы делим эту функцию на три части», за которыми следуют большие длинные строки // ------------------между каждой частью.
• Вы также можете поместить каждую часть расчета в свою собственную область. Это дает преимущество немедленного доказательства, вне всяких сомнений, что нет разделения переменных между частями.

РЕДАКТИРОВАТЬ: После просмотра вашего редактирования с примером кода, я склоняюсь к тому, что примечание комментариев является наиболее чистым, с скобками, чтобы обеспечить границы, предлагаемые комментариями. Однако, если какие-либо функции можно использовать в других функциях, я бы рекомендовал использовать функции вместо

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 ++, дизайн OO не обязателен.