Esse é um bom padrão: substituir uma função longa por uma série de lambdas?

Recentemente, encontrei a seguinte situação.

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

Em primeiro lugar, Arepresenta um objeto no mundo físico, que é um forte argumento para não dividir a classe. Agora, calculate()acaba por ser uma função bastante longa e complicada. Eu percebo três estruturas possíveis para isso:

• escreva como uma parede de texto - vantagens - todas as informações estão em um só lugar
• escrever privatefunções utilitárias na classe e usá-las no calculatecorpo da pessoa - desvantagens - o resto da classe não conhece / se importa / entende sobre esses métodos

• escreva calculateda seguinte maneira:

  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);
  }

Isso pode ser considerado uma boa ou má prática? Essa abordagem revela algum problema? Em suma, devo considerar isso uma boa abordagem quando me encontrar novamente com a mesma situação?

EDITAR:

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.
    ...
}

Todos esses métodos:

• obter um valor
• calcular alguns outros valores, sem usar state
• chame alguns dos "objetos de submodelo" para alterar seu estado.

Acontece que, exceto set_room_size(), esses métodos simplesmente passam o valor solicitado para subobjetos. set_room_size(), por outro lado, faz algumas telas de fórmulas obscuras e (2) faz meia tela de chamada de setters de subobjetos para aplicar os vários resultados obtidos. Portanto, eu separei a função em duas lambdas e as chamo no final da função. Se eu fosse capaz de dividi-lo em pedaços mais lógicos, eu teria isolado mais lambdas.

Independentemente disso, o objetivo da pergunta atual é determinar se esse modo de pensar deve persistir ou, na melhor das hipóteses, não agrega valor (legibilidade, capacidade de manutenção, capacidade de depuração etc.).

Não, esse geralmente não é um bom padrão

O que você está fazendo é dividir uma função em funções menores usando lambda. No entanto, existe uma ferramenta muito melhor para dividir funções: funções.

Os lambdas funcionam, como você viu, mas significam muito muito muito muito mais do que simplesmente dividir uma função em bits locais. Lambdas do:

• Encerramentos. Você pode usar variáveis ​​no escopo externo dentro do lambda. Isso é muito poderoso e muito complicado.
• Reatribuição. Enquanto seu exemplo dificulta a tarefa, é preciso sempre prestar atenção à idéia de que o código pode trocar funções a qualquer momento.
• Funções de primeira classe. Você pode passar uma função lambda para outra função, fazendo algo conhecido como "programação funcional".

No instante em que você introduz lambdas no mix, o próximo desenvolvedor a examinar o código deve carregar imediatamente todas essas regras mentalmente, preparando-se para ver como seu código funciona. Eles não sabem que você não vai usar toda essa funcionalidade. Isso é muito caro, comparado às alternativas.

É como usar uma enxada para fazer sua jardinagem. Você sabe que só o está usando para cavar pequenos orifícios para as flores deste ano, mas os vizinhos ficam nervosos.

Considere que tudo o que você está fazendo é agrupar seu código-fonte visualmente. O compilador realmente não se importa que você tenha curry coisas com lambdas. Na verdade, espero que o otimizador desfaça imediatamente tudo o que você fez quando compila. Você está puramente atendendo ao próximo leitor (obrigado por fazer isso, mesmo se discordarmos da metodologia! O código é lido com muito mais frequência do que está escrito!). Tudo o que você está fazendo é agrupar a funcionalidade.

• As funções colocadas localmente no fluxo do código-fonte também funcionariam, sem chamar o lambda. Novamente, tudo o que importa é que o leitor possa lê-lo.
• Comentários na parte superior da função dizendo "estamos dividindo esta função em três partes", seguidos por grandes linhas longas // ------------------entre cada parte.
• Você também pode colocar cada parte do cálculo em seu próprio escopo. Isso tem o bônus de provar imediatamente, sem sombra de dúvida, que não há compartilhamento variável entre as partes.

EDIT: Ao ver sua edição com código de exemplo, inclino-me para que a notação de comentário seja a mais limpa, com colchetes para impor os limites sugeridos pelos comentários. No entanto, se alguma funcionalidade foi reutilizável em outras funções, eu recomendaria o uso de funções.

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}
        ...
    }
}

Eu acho que você fez uma suposição ruim:

Em primeiro lugar, A representa um objeto no mundo físico, que é um forte argumento para não dividir a classe.

Eu discordo disso. Por exemplo, se eu tivesse uma classe que representa um carro, eu definitivamente gostaria de dividi-la, porque certamente quero uma classe menor para representar os pneus.

Você deve dividir essa função em funções privadas menores. Se realmente parecer separado da outra parte da classe, isso pode ser um sinal de que a classe deve ser separada. Claro que é difícil dizer sem um exemplo explícito.

Eu realmente não vejo a vantagem de usar funções lambda nesse caso, porque realmente não torna o código mais limpo. Eles foram criados para ajudar na programação de estilos funcionais, mas não é isso.

O que você escreveu se assemelha um pouco aos objetos de função aninhada no estilo Javascript. O que é novamente um sinal de que eles pertencem firmemente juntos. Tem certeza de que não deve fazer uma aula separada para eles?

Para resumir, não acho que esse seja um bom padrão.

ATUALIZAR

Se você não encontrar nenhuma maneira de encapsular essa funcionalidade em uma classe significativa, poderá criar funções auxiliares com escopo no arquivo, que não são membros da sua classe. Afinal, este é C ++, o design do OO não é obrigatório.