"Le nombre idéal d'arguments pour une fonction est zéro" est tout simplement faux. Le nombre idéal d'arguments est exactement le nombre nécessaire pour permettre à votre fonction d'être sans effet secondaire. Moins que cela et vous faites inutilement impur vos fonctions, vous forçant ainsi à vous éloigner du gouffre du succès et à gravir le gradient de la douleur. Parfois, "Oncle Bob" est sur place avec ses conseils. Parfois, il se trompe de façon spectaculaire. Son avis zéro argument est un exemple de ce dernier
( Source: commentaire de @David Arno sous une autre question sur ce site )
Le commentaire a gagné un nombre spectaculaire de 133 votes positifs, c'est pourquoi j'aimerais porter une attention particulière à son mérite.
Pour autant que je sache, il y a deux façons distinctes dans la programmation: la programmation fonctionnelle pure (ce que ce commentaire est encourageant) et dites, ne demandez pas (qui de temps en temps est également recommandé sur ce site). AFAIK ces deux principes sont fondamentalement incompatibles, proches d'être opposés l'un à l'autre: le pur fonctionnel peut être résumé comme "seulement des valeurs de retour, sans effets secondaires" tandis que dire, ne pas demander peut être résumé comme "ne retourne rien, avoir que des effets secondaires ". De plus, je suis un peu perplexe parce que je pensais que dire, ne pas demander était considéré comme le cœur du paradigme OO tandis que les fonctions pures étaient considérées comme le cœur du paradigme fonctionnel - maintenant je vois des fonctions pures recommandées dans OO!
Je suppose que les développeurs devraient probablement choisir l'un de ces paradigmes et s'y tenir? Eh bien, je dois admettre que je ne pourrais jamais me résoudre à suivre non plus. Souvent, il me semble pratique de renvoyer une valeur et je ne vois pas vraiment comment puis-je atteindre ce que je veux réaliser uniquement avec des effets secondaires. Souvent, cela me semble pratique d'avoir des effets secondaires et je ne vois pas vraiment comment puis-je atteindre ce que je veux réaliser uniquement en renvoyant des valeurs. De plus, souvent (je suppose que c'est horrible), j'ai des méthodes qui font les deux.
Cependant, à partir de ces 133 votes positifs, je raisonne que la programmation fonctionnelle actuellement pure "gagne" car cela devient un consensus qu'il est supérieur de dire, ne demandez pas. Est-ce correct?
Par conséquent, sur l'exemple de ce jeu anti-modèles, j'essaie de faire : Si je voulais le mettre en conformité avec le paradigme fonctionnel pur - COMMENT?!
Il me semble raisonnable d'avoir un état de bataille. Comme il s'agit d'un jeu au tour par tour, je garde les états de bataille dans un dictionnaire (multijoueur - il peut y avoir plusieurs batailles jouées par plusieurs joueurs en même temps). Chaque fois qu'un joueur fait son tour, j'appelle une méthode appropriée sur l'état de bataille qui (a) modifie l'état en conséquence et (b) renvoie des mises à jour aux joueurs, qui sont sérialisées en JSON et leur dis simplement ce qui vient de se passer sur le planche. Je suppose que cela constitue une violation flagrante des DEUX principes et en même temps.
OK - Je pourrais faire en sorte qu'une méthode RETOURNE un état de bataille au lieu de la modifier si je le voulais vraiment. Mais! Dois-je alors tout copier inutilement dans l'état de combat juste pour retourner un état entièrement nouveau au lieu de le modifier en place?
Maintenant, peut-être que si le mouvement est une attaque, je pourrais simplement renvoyer un personnage mis à jour HP? Le problème est que ce n'est pas si simple: les règles du jeu, un coup peut et aura souvent beaucoup plus d'effets que de simplement supprimer une partie des HP d'un joueur. Par exemple, cela peut augmenter la distance entre les personnages, appliquer des effets spéciaux, etc., etc.
Il me semble tellement plus simple de simplement modifier l'état en place et de renvoyer les mises à jour ...
Mais comment un ingénieur expérimenté pourrait-il résoudre ce problème?