Liste de paramètres longue versus liste de variables d'état long

Dans un livre C ++, l'auteur dit que nous n'avons plus besoin d'une fonction avec une longue liste de paramètres car la plupart des paramètres peuvent être refactorisés en variables d'état dans une classe. D'un autre côté, un livre de programmation fonctionnelle dit que les variables d'état sont mauvaises car elles provoquent des effets secondaires qui provoquent des bogues et des problèmes de parallélisation du code. Je suis perplexe. Le code doit-il éviter autant que possible de s'appuyer sur des variables d'état en déplaçant sa variable d'état dans la liste des paramètres de fonction?

Cela dépend si vous programmez dans un proceduralou un functionalparadigme. Un état mutable est requis pour les premiers et paralysant pour les derniers. Ce sont des pommes et des oranges. Ils ont tous les deux raison sur leurs bailiwicks!

Vous pouvez appliquer une affectation unique et d'autres techniques fonctionnelles aux langages procéduraux impératifs, l'état immuable rend la programmation simultanée plus déterministe, mais rendre chaque objet immuable dans un langage comme Java ou C ++ est presque impossible car leurs modèles de mémoire ne prennent pas facilement en charge ce paradigme.

Si je comprends bien votre question, vous vous demandez quelles conditions qualifient l'utilisation d'un paramètre ou d'une variable de classe / membre / champ / etc? Je suppose que vous faites référence à une méthode et non à une fonction. S'il s'agit spécifiquement de C ++, je suggère de déplacer votre question vers le débordement de pile.

Une longue liste de paramètres peut être un signe que vous devrez peut-être refactoriser votre méthode en un ensemble de plus granulaires. Généralement, l'utilisation de paramètres rendra votre code plus lâche. Je ne sais plus si cela est vrai pour la plupart des langages OO modernes, mais la création d'objets peut être coûteuse, surtout si de nombreuses variables de classe sont impliquées; ainsi, si vos variables de classe étaient des objets et étaient fréquemment référencées dans un programme, elles peuvent être justifiées comme étant des variables de classe.

Aussi:

• D'autres méthodes pourraient-elles utiliser les variables de classe? Si oui, envisagez d'utiliser des variables de classe.
• Votre méthode est-elle publique? S'il est public, utilisez des paramètres.
• Votre liste de paramètres peut-elle être représentée de manière appropriée comme un hachage / carte / tableau / collection / liste / etc? Si oui, considérez-le comme une option.
• Votre méthode est-elle statique? Si oui, utilisez des paramètres.

Non, les variables d'état en soi ne provoquent pas d' effets secondaires.

L'appel d'une méthode de définition (sur une structure de données visible ailleurs) est un effet secondaire.

Vous pouvez avoir des structures de données pour masquer les longues listes de paramètres et éviter les effets secondaires si vous les construisez en conséquence. Voici un petit exemple (en Java, non testé):

class ManyParams {
    final String theName = null;
    final int    theAge = 0:
    ManyParams() {}
    ManyParams(String a, int b) { theName=a; theAge = b; }
    public withName(String n) {
        return new ManyParams(n, this.theAge);
    }
    public withAge(int i) {
         return new ManyParams(theName, i);
    }
}
/// to be used like this
foo(new ManyParams.withName("John").withAge(42));

Bien sûr, le constructeur de ManyParams aura toujours une longue liste de paramètres de cette façon. Mais c'est caché.