J'ai récemment remarqué que lorsque je crée des méthodes privées qui définissent quelques champs dans les objets qui leur ont transmis que Resharper pose une indication indiquant que la méthode peut être faite statique.
Voici un exemple très simplifié de la Une sorte de méthode que je pourrais avoir. Lorsque j'ai une méthode comme celle-ci, RESHARPER fournit une recommandation que la méthode peut être faite statique. J'essaie d'éviter de faire des méthodes publiques statiques car elles épuisent des tests unitaires ... mais je ne suis pas sûr que la même chose s'applique aux méthodes privées. est la recommandation du Restomes une meilleure pratique valide ou devrais-je il suffit de l'éteindre?
4 Réponses :
Je pense que c'est certainement un candidat principal pour une méthode statique. Il ne modifie aucune des propriétés, des champs, etc. de la classe, etc. Voici un exemple: aussi, vous pouvez en faire une méthode d'extension (qui serait également statique ):
Je pense que oui; Voir qu'une méthode est statique est une indication claire que la méthode doit pas interagir avec des membres d'instance.
Imaginez déboguer une méthode non statique et réaliser l'instance n'est pas touchée. Odeur instantanée et s'il n'y a pas de commentaire expliquant quelle est la fonction, vous pourriez être distrait du vrai problème.
+1 Pour préciser que la méthode ne doit pas interagir avec des membres d'instance. Je veux certainement que les gens réfléchissent à deux fois avant de modifier ce code particulier avec des appels aux méthodes des membres de l'instance. En marquant la méthode privée statique si une personne a modifié le code pour utiliser un membre d'instance, ils obtiennent un avertissement de compilation qui devrait au moins les faire penser pendant quelques secondes.
J'avais R # Recommander une méthode statique il y a quelques minutes seulement, seulement pour trouver une erreur de compilation essayant d'accéder à un champ d'instance. Première fois que cela a eu lieu, quelque chose doit l'avoir confondu.
Que voulez-vous dire par interaction? Modifier les valeurs? Ou cela inclut les valeurs de lecture?
@guiomie, soit de ces opérations. Par exemple, string.isnullorempty () prend comme paramètre les données qu'il utilise plutôt que d'utiliser une valeur d'élément d'instance.
Je vais habituellement avec la recommandation de R #. C'est une méthode privée, alors (espérons-le), vous n'écrivez pas les tests d'unité contre elle. Rendre statique explicitement indique qu'il n'utilise aucun membre d'instance, ce qui facilite l'inspection des effets secondaires.
au risque de sonner comme un contrarian, je dois admettre que je n'aime pas mélanger des méthodes statiques avec des méthodes d'instance; et je n'aime pas les méthodes statiques en général. Les méthodes statiques sont difficiles à tester, difficiles à remplacer et difficiles à entretenir. Je préfère coller toutes les méthodes statiques pour traiter des objets FOO dans une seule classe fooutils - ou, mieux encore, dans une instance singleton d'une classe FoosomoReDayer.
Bien entendu, les méthodes statiques ont parfaitement logique dans certains cas - par exemple, lors de la création des singletons, ou des usines susmentionnées, etc. Je ne dis pas que toutes les méthodes statiques sont constituées d'un mal pur; Je préfère simplement vous tromper du côté de les éviter lorsque cela est possible.
Je suis d'accord. Je ne fais que faire des méthodes statiques quand il est logique de, pas seulement parce que je "peux".
Je suis d'accord pour les méthodes publiques, protégées et internes - mais pas pour les méthodes privées. Il y a quelques discussions sur le net si les classes utilisées sont une odeur de code; Je suggérerais de les utiliser avec soin.
D'accord. Faire une méthode statique est une tentative de communication d'informations relatives à l'utilisation de cette méthode. Faire tout statique n'a aucun sens.
Les méthodes publiques sont totalement testables, s'ils ne causent pas d'effets secondaires.