La méthode peut être rendue statique, mais devrait-elle l'être?

Resharper aime souligner plusieurs fonctions par page asp.net qui pourraient être rendues statiques. Est-ce que cela m'aide à les rendre statiques? Dois-je les rendre statiques et les déplacer vers une classe utilitaire?

Méthodes statiques et méthodes d'instance
10.2.5 Les membres statiques et d'instance de la spécification de langage C # expliquent la différence. Généralement, les méthodes statiques peuvent fournir une très petite amélioration des performances par rapport aux méthodes d'instance, mais uniquement dans des situations quelque peu extrêmes (voir cette réponse pour plus de détails à ce sujet).

La règle CA1822 dans FxCop ou l'analyse de code indique:

"Après [le marquage des membres comme statiques], le compilateur émettra des sites d'appels non virtuels vers ces membres, ce qui empêchera une vérification au moment de l'exécution pour chaque appel qui garantit que le pointeur d'objet actuel n'est pas nul. Cela peut entraîner un gain de performances mesurable pour le code sensible aux performances. Dans certains cas, l'échec de l'accès à l'instance d'objet actuelle représente un problème de correction. "

Classe utilitaire
Vous ne devez pas les déplacer vers une classe utilitaire à moins que cela ait du sens dans votre conception. Si la méthode statique se rapporte à un type particulier, comme une ToRadians(double degrees)méthode se rapporte à une classe représentant des angles, il est logique que cette méthode existe en tant que membre statique de ce type (notez qu'il s'agit d'un exemple compliqué à des fins de démonstration).

Les performances, la pollution de l'espace de noms, etc. sont toutes secondaires à mon avis. Demandez-vous ce qui est logique. La méthode fonctionne-t-elle logiquement sur une instance du type ou est-elle liée au type lui-même? Si c'est le dernier, faites-en une méthode statique. Déplacez-le uniquement dans une classe utilitaire s'il est lié à un type qui n'est pas sous votre contrôle.

Parfois, il existe des méthodes qui agissent logiquement sur une instance mais qui n'utilisent pas encore l' état de l'instance . Par exemple, si vous construisez un système de fichiers et que vous avez le concept d'un répertoire, mais que vous ne l'avez pas encore implémenté, vous pouvez écrire une propriété renvoyant le type de l'objet du système de fichiers, et ce serait toujours juste "fichier" - mais il est logiquement lié à l'instance, et devrait donc être une méthode d'instance. Ceci est également important si vous souhaitez rendre la méthode virtuelle - votre implémentation particulière peut ne pas avoir besoin d'état, mais les classes dérivées le peuvent. (Par exemple, demander à une collection si elle est en lecture seule ou non - vous n'avez peut-être pas encore implémenté une forme en lecture seule de cette collection, mais c'est clairement une propriété de la collection elle-même, pas le type.)

En marquant une méthode comme staticdans une classe, il est évident qu'elle n'utilise aucun membre d'instance, ce qui peut être utile pour savoir quand parcourir le code.

Vous n'avez pas nécessairement à le déplacer vers une autre classe, sauf s'il est destiné à être partagé par une autre classe qui est tout aussi étroitement associée, conceptuellement.

Je suis sûr que cela ne se produit pas dans votre cas, mais une "mauvaise odeur" que j'ai vue dans un code que j'ai dû souffrir en maintenant utilisé un tas de méthodes statiques.

Malheureusement, il s'agissait de méthodes statiques qui supposaient un état d'application particulier. (pourquoi bien sûr, nous n'aurons qu'un seul utilisateur par application! Pourquoi ne pas laisser la classe User garder une trace de cela dans les variables statiques?) Ils étaient des moyens glorifiés d'accéder aux variables globales. Ils avaient également des constructeurs statiques (!), Ce qui est presque toujours une mauvaise idée. (Je sais qu'il y a quelques exceptions raisonnables).

Cependant, les méthodes statiques sont très utiles lorsqu'elles tiennent compte de la logique du domaine qui ne dépend pas réellement de l'état d'une instance de l'objet. Ils peuvent rendre votre code beaucoup plus lisible.

Assurez-vous simplement de les mettre au bon endroit. Les méthodes statiques manipulent-elles de manière intrusive l'état interne d'autres objets? Peut-on démontrer que leur comportement appartient à l'une de ces classes? Si vous ne séparez pas correctement les préoccupations, vous pourriez avoir des maux de tête plus tard.

Ceci est intéressant à lire:

http://thecuttingledge.com/?p=57

ReSharper ne suggère pas réellement que vous rendiez votre méthode statique. Vous devriez vous demander pourquoi cette méthode est dans cette classe par opposition à, disons, l'une des classes qui apparaît dans sa signature ...

mais voici ce que dit la documentation de resharper: http://confluence.jetbrains.net/display/ReSharper/Member+can+be+made+static

Juste pour ajouter à la réponse de @Jason True , il est important de réaliser que le simple fait de mettre 'statique' sur une méthode ne garantit pas que la méthode sera 'pure'. Il sera sans état en ce qui concerne la classe dans laquelle il est déclaré, mais il peut très bien accéder à d'autres objets `` statiques '' qui ont un état (configuration d'application, etc.), ce n'est pas toujours une mauvaise chose, mais l'une des raisons pour lesquelles Personnellement, j'ai tendance à préférer les méthodes statiques quand je peux, c'est que si elles sont pures, vous pouvez les tester et les raisonner isolément, sans avoir à vous soucier de l'état environnant.

Vous devez faire ce qui est le plus lisible et intuitif dans un scénario donné.

L'argument de performance n'est pas bon, sauf dans les situations les plus extrêmes, car la seule chose qui se passe réellement est qu'un paramètre supplémentaire ( this) est poussé sur la pile pour les méthodes d'instance.

Pour la logique complexe au sein d'une classe, j'ai trouvé des méthodes statiques privées utiles pour créer une logique isolée, dans laquelle les entrées d'instance sont clairement définies dans la signature de la méthode et aucun effet secondaire d'instance ne peut se produire. Toutes les sorties doivent être via la valeur de retour ou les paramètres out / ref. Décomposer une logique complexe en blocs de code sans effet secondaire peut améliorer la lisibilité du code et la confiance de l'équipe de développement en lui.

En revanche, elle peut conduire à une classe polluée par une prolifération de méthodes d'utilité. Comme d'habitude, la dénomination logique, la documentation et l'application cohérente des conventions de codage d'équipe peuvent atténuer ce problème.

ReSharper ne vérifie pas la logique. Il vérifie uniquement si la méthode utilise des membres d'instance. Si la méthode est privée et appelée uniquement par (peut-être une seule) méthodes d'instance, c'est un signe pour lui laisser une méthode d'instance.

Si les fonctions sont partagées sur plusieurs pages, vous pouvez également les placer dans une classe de page de base, puis faire hériter toutes les pages asp.net de cette fonctionnalité (et les fonctions peuvent toujours être statiques également).

Rendre une méthode statique signifie que vous pouvez appeler la méthode depuis l'extérieur de la classe sans créer d'abord une instance de cette classe. Cela est utile lorsque vous travaillez avec des objets ou des modules complémentaires tiers. Imaginez si vous deviez d'abord créer un objet Console "con" avant d'appeler con.Writeline ();

Il aide à contrôler la pollution de l'espace de noms.

Juste ma tuppence: l'ajout de toutes les méthodes statiques partagées à une classe utilitaire vous permet d'ajouter

using static className; 

à vos instructions using, ce qui rend le code plus rapide à taper et plus facile à lire. Par exemple, j'ai un grand nombre de ce qu'on pourrait appeler des "variables globales" dans un code dont j'ai hérité. Plutôt que de créer des variables globales dans une classe qui était une classe d'instance, je les ai toutes définies comme propriétés statiques d'une classe globale. Il fait le travail, s'il est désordonné, et je peux simplement référencer les propriétés par nom car j'ai l'espace de noms statique déjà référencé.

Je ne sais pas si c'est une bonne pratique ou non. J'ai tellement de choses à apprendre sur C # 4/5 et tellement de code hérité à refactoriser que j'essaie simplement de me laisser guider par les conseils de Roselyn.

Joey

J'espère que vous avez déjà compris la différence entre les méthodes statiques et d'instance. En outre, il peut y avoir une réponse longue et une réponse courte. Des réponses longues sont déjà fournies par d'autres.

Ma réponse courte: Oui, vous pouvez les convertir en méthodes statiques si Resharper le suggère. Il n'y a aucun mal à le faire. Au contraire, en rendant la méthode statique, vous protégez réellement la méthode afin que, inutilement, vous ne glissiez aucun membre d'instance à cette méthode. De cette façon, vous pouvez réaliser un principe de POO " Minimiser l'accessibilité des classes et des membres ".

Lorsque ReSharper suggère qu'une méthode d'instance peut être convertie en une méthode statique, il vous dit en fait: "Pourquoi la .. cette méthode se trouve dans cette classe car elle n'utilise en fait aucun de ses états?" Donc, cela vous donne matière à réflexion. Ensuite, c'est vous qui pouvez réaliser le besoin de déplacer cette méthode vers une classe utilitaire statique ou non. Selon les principes SOLID, une classe ne devrait avoir qu'une seule responsabilité principale. Ainsi, vous pouvez faire un meilleur nettoyage de vos classes de cette façon. Parfois, vous avez besoin de certaines méthodes d'assistance, même dans votre classe d'instance. Si tel est le cas, vous pouvez les conserver dans un assistant #region.