Est-ce un bon schéma: remplacer une fonction longue par une série de lambdas?

J'ai récemment rencontré la situation suivante.

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

Premièrement, Areprésente un objet dans le monde physique, ce qui est un argument fort pour ne pas diviser la classe. Maintenant, cela calculate()s'avère être une fonction assez longue et compliquée. J'en perçois trois structures possibles:

• l'écrire comme un mur de texte - avantages - toutes les informations sont en un seul endroit
• écrire des privatefonctions utilitaires dans la classe et les utiliser dans calculatele corps de - inconvénients - le reste de la classe ne sait pas / ne prend pas soin / ne comprend pas ces méthodes

• écrivez de calculatela manière suivante:

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

Cela peut-il être considéré comme une bonne ou une mauvaise pratique? Cette approche révèle-t-elle des problèmes? Dans l'ensemble, dois-je considérer cela comme une bonne approche lorsque je suis à nouveau confronté à la même situation?

ÉDITER:

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

Toutes ces méthodes:

• obtenir une valeur
• calculer d'autres valeurs, sans utiliser l'état
• appeler certains des "objets de sous-modèle" pour changer leur état.

Il s'avère que, sauf que set_room_size()ces méthodes transmettent simplement la valeur demandée aux sous-objets. set_room_size(), d'autre part, fait un couple d'écrans de formules obscures, puis (2) fait un demi-écran d'appel de sous-objets setters pour appliquer les différents résultats obtenus. Par conséquent, j'ai séparé la fonction en deux lambdas et je les appelle à la fin de la fonction. Si j'avais pu le diviser en morceaux plus logiques, j'aurais isolé plus de lambdas.

Quoi qu'il en soit, l'objectif de la question actuelle est de déterminer si cette façon de penser doit persister, ou au mieux ne pas ajouter de valeur (lisibilité, maintenabilité, capacité de débogage, etc.).

Non, ce n'est généralement pas un bon schéma

Ce que vous faites est de diviser une fonction en fonctions plus petites à l'aide de lambda. Cependant, il existe un bien meilleur outil pour décomposer les fonctions: les fonctions.

Les lambdas fonctionnent, comme vous l'avez vu, mais ils signifient beaucoup beaucoup beaucoup plus que la simple décomposition d'une fonction en bits locaux. Les Lambdas font:

• Fermetures. Vous pouvez utiliser des variables dans la portée externe à l'intérieur du lambda. C'est très puissant et très compliqué.
• Réaffectation. Bien que votre exemple rende difficile la tâche d'affectation, il faut toujours faire attention à l'idée que le code peut permuter les fonctions à tout moment.
• Fonctions de première classe. Vous pouvez passer une fonction lambda à une autre fonction, en faisant quelque chose appelé «programmation fonctionnelle».

À l'instant où vous introduisez des lambdas dans le mélange, le prochain développeur à regarder le code doit immédiatement charger mentalement toutes ces règles afin de voir comment fonctionne votre code. Ils ne savent pas que vous n'utiliserez pas toutes ces fonctionnalités. C'est très cher par rapport aux alternatives.

C'est comme utiliser une pelle rétrocaveuse pour faire votre jardinage. Vous savez que vous ne l'utilisez que pour creuser de petits trous pour les fleurs de cette année, mais les voisins deviendront nerveux.

Considérez que tout ce que vous faites est de regrouper visuellement votre code source. Le compilateur ne se soucie pas vraiment que vous curiez les choses avec des lambdas. En fait, je m'attendrais à ce que l'optimiseur annule immédiatement tout ce que vous venez de faire lors de la compilation. Vous vous adressez uniquement au lecteur suivant (merci de le faire, même si nous ne sommes pas d'accord sur la méthodologie! Le code est lu beaucoup plus souvent qu'il n'est écrit!). Tout ce que vous faites, c'est regrouper des fonctionnalités.

• Les fonctions placées localement dans le flux de code source feraient tout aussi bien, sans invoquer lambda. Encore une fois, tout ce qui compte, c'est que le lecteur puisse le lire.
• Commentaires en haut de la fonction indiquant "nous divisons cette fonction en trois parties", suivis de grandes longues lignes // ------------------entre chaque partie.
• Vous pouvez également placer chaque partie du calcul dans sa propre étendue. Cela a l'avantage de prouver immédiatement hors de tout doute qu'il n'y a pas de partage variable entre les pièces.

EDIT: En voyant votre édition avec un exemple de code, je penche pour que la notation des commentaires soit la plus propre, avec des crochets pour appliquer les limites suggérées par les commentaires. Cependant, si l'une des fonctionnalités était réutilisable dans d'autres fonctions, je recommanderais d'utiliser des fonctions à la place

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

Je pense que vous avez fait une mauvaise hypothèse:

Premièrement, A représente un objet dans le monde physique, ce qui est un argument solide pour ne pas diviser la classe.

Je suis en désaccord avec cela. Par exemple, si j'avais une classe qui représente une voiture, je voudrais certainement la diviser, car je veux sûrement une classe plus petite pour représenter les pneus.

Vous devez diviser cette fonction en petites fonctions privées. Si elle semble vraiment séparée de l'autre partie de la classe, cela peut être un signe que la classe doit être séparée. Bien sûr, c'est difficile à dire sans un exemple explicite.

Je ne vois pas vraiment l'avantage d'utiliser les fonctions lambda dans ce cas, car cela ne rend pas vraiment le code plus propre. Ils ont été créés pour faciliter la programmation de style fonctionnel, mais ce n'est pas ça.

Ce que vous avez écrit ressemble un peu aux objets de fonction imbriqués de style Javascript. Ce qui est encore une fois le signe qu'ils sont étroitement liés. Etes-vous sûr que vous ne devriez pas faire une classe séparée pour eux?

Pour résumer, je ne pense pas que ce soit un bon schéma.

MISE À JOUR

Si vous ne voyez aucun moyen d'encapsuler cette fonctionnalité dans une classe significative, vous pouvez créer des fonctions d'assistance à portée de fichier, qui ne sont pas membres de votre classe. C'est du C ++ après tout, la conception OO n'est pas un must.