Pourquoi devrions-nous éviter de définir des méthodes avec plus de trois paramètres, du point de vue du code propre?

Cela dépend, si vous utilisiez des modèles de conception (mais pas vraiment), votre logique de code vous permettrait de recevoir quelque chose comme (données de tableau, un objet, un indicateur (facultatif)) comme paramètres maximum requis.

Il s'agit de prendre du code volumineux et de le rendre aussi petit et réutilisable que possible. Plus ou moins, vous avez des données / objets que vous traitez et faites des choses.

Ceci n'est que mon opinion en ce qui concerne la déclaration suggérée. Bien sûr, il y a des moments où cela ne s'applique pas, mais vous pouvez essayer de créer des morceaux de code comme des blocs Lego qui peuvent construire quelque chose.

Vous pouvez utiliser ce que vous voulez.

Juste pour la lisibilité du code, il est censé être le moins de paramètres possible dans les méthodes et il n'y a aucune restriction sur le nombre de paramètres, vous pourriez avoir 4 ou 6 paramètres et ce serait raisonnable dans certains cas. Si vous n'aimez pas beaucoup de variables de classe privées, vous êtes libre de transmettre ces variables en tant que paramètres à votre méthode, parlez simplement aux personnes avec lesquelles vous travaillez et choisissez votre style ensemble.

C'est un art de décider quelle décision serait la meilleure pour la poursuite du programme.

Je pense que cette recommandation est une bonne règle de base, mais je ne la traiterais pas comme une règle absolue. Dans certains cas, il doit simplement y avoir plus de trois paramètres.

Les raisons d'éviter de nombreux paramètres sont que les méthodes avec moins de paramètres sont en général plus faciles à lire, à comprendre et à utiliser. Cela peut également indiquer qu'une méthode fait beaucoup de travail. Les méthodes et les classes sont plus faciles à comprendre et à utiliser si elles ont un seul objectif clair et ne font pas beaucoup de choses différentes en une seule fois.

Si une méthode a beaucoup de paramètres, il y a quelques options à considérer:

• Est-il judicieux de promouvoir des paramètres dans une dépendance? Une indication pour cela est si vous utilisez toujours le même objet pour un paramètre pour tous les appels à la méthode.
• Est-il judicieux de promouvoir des paramètres en propriétés?
• Certains paramètres peuvent-ils être facultatifs? Ou ajouter des surcharges ou des méthodes d'extension avec moins de paramètres? Cela peut rendre la méthode plus facile à utiliser si l'appelant n'a pas à se soucier des choses dont il n'a pas besoin.
• Est-il judicieux de créer un objet paramètre contenant plusieurs valeurs? Cela peut être indiqué si certaines valeurs sont souvent utilisées ensemble. Un exemple serait les objets Pen ou font utilisés dans GDI. C'est surtout utile si l'objet peut être réutilisé pour plusieurs appels.
• Serait-il judicieux de déplacer la méthode vers une nouvelle classe qui prend certains des paramètres du constructeur? Cela serait également indiqué si plusieurs appels partagent des paramètres.
• Pouvez-vous augmenter le niveau d'abstraction? Un exemple serait une méthode pour calculer la distance entre deux points qui prend x, y, z pour chaque point. La création d'un type pour les points, les lignes, etc. gardera la plupart des méthodes courtes, simples et faciles à comprendre.

Cela dit, le nombre de paramètres n'est qu'une partie de ce qui fait qu'une méthode est bien conçue. Si aucune des options ne rend votre code plus facile à utiliser et à comprendre, laissez-le faire.