Méthode peut être faite en statique, mais il devrait ?

Question

Resharper aime à souligner des fonctions multiples par page asp.net qui pourraient être statique. Il m’aide si je ne leur donneraient pas statique ? Dois-je rendre statique et déplacez-les vers une classe utilitaire ?

Answer 1

De la Performance, de l'espace de noms de la pollution, etc sont tous secondaire à mon avis. Demandez-vous ce qui est logique. La méthode est logiquement d'exploitation sur une instance du type, ou est-il lié au type de lui-même? Si c'est le second, à une méthode statique. Seulement le déplacer dans une classe utilitaire si c'est lié à un type qui n'est pas sous votre contrôle.

Parfois, il existe des méthodes qui, logiquement, loi sur une instance, mais n'arrive pas à utiliser l'un de l'instance de l'état encore. Par exemple, si vous avez été la construction d'un système de fichiers et vous auriez eu la notion de répertoire, mais vous n'aviez pas encore mise en oeuvre, vous pourriez écrire une propriété de retourner le type de l'objet système de fichiers, et il serait toujours juste "fichier" - mais c'est logiquement liée à l'instance, et devrait donc être une méthode d'instance. C'est également important si vous voulez faire de la méthode virtuelle de votre application peuvent ne pas avoir besoin de l'état, mais les classes dérivées peuvent. (Par exemple, en posant une collection de savoir si ou non il est en lecture seule, vous ne pouvez pas avoir mis en place un formulaire en lecture seule de cette collection pour le moment, mais c'est clairement une propriété de la collection elle-même, pas le type.)

Answer 2

Méthodes statiques versus les méthodes d'Instance
10.2.5 Statique et les membres de l'instance de la Spécification du Langage C# qui explique la différence. Généralement, les méthodes statiques ne peuvent fournir une très faible amélioration de la performance (sans parler de la mémoire de l'épargne en fonction du nombre d'instances de la classe peut s'attendre à créer) sur les méthodes d'instance, mais seulement un peu dans des situations extrêmes.

La règle CA1822 dans FxCop ou d'Analyse de Code unis:

"Après marquage des membres static], le compilateur émet non-virtuel sites d'appel à ces membres qui permettra d'éviter un chèque à d'exécution pour chaque appel qui assure l'objet pointeur est non null. Cela peut entraîner un gain de performance mesurables pour performance sensibles au code. Dans certains cas, l'impossibilité d'accès à la instance actuelle de l'objet représente une exactitude problème."

Classe Utilitaire
Vous ne devriez pas aller pour une classe utilitaire, sauf si elle fait sens dans votre conception. Si la méthode statique se rapporte à un type particulier, comme un ToRadians(doubles diplômes) méthode se rapporte à une classe représentant les angles, il est logique de cette méthode pour exister en tant que membre statique de ce type (remarque, c'est un alambiqué exemple pour les besoins de la démonstration).

Answer 3

Une application de la méthode de marquage `` dans une classe rend évident qu’il n’utilise pas les membres de l’instance qui peuvent être utiles de savoir quand l’écrémage dans le code. Vous n’avez pas nécessairement pour le déplacer vers une autre classe à moins qu’il est destiné à être partagé par une autre classe qui a juste comme étroitement associé, concept-wise.

Answer 4

Je suis sûr que ce n'est pas votre cas, mais une "mauvaise odeur" j'ai vu dans certains code que j'ai eu à souffrir de maintien utilisé un diable de beaucoup de méthodes statiques.

Malheureusement, ils ont des méthodes statiques qui suppose une application particulière de l'état. (pourquoi bien sûr, nous allons avoir un seul utilisateur par application! Pourquoi ne pas avoir la classe Utilisateur de garder une trace de cela dans les variables statiques?) Ils ont été glorifiés moyens d'accéder aux variables globales. Ils avaient aussi des constructeurs statiques (!), qui sont presque toujours une mauvaise idée. (Je sais qu'il y a un couple de des exceptions raisonnables).

Cependant, les méthodes statiques sont très utiles lorsqu'ils facteur de domaine logique qui n'est pas réellement dépendent de l'état d'une instance de l'objet. Ils peuvent faire de votre code beaucoup plus lisible.

Juste être sûr que vous êtes de les mettre dans le bon endroit. Sont les méthodes statiques dommage manipulation de l'état interne d'autres objets? Peut bien être fait que leur comportement appartient à l'une de ces classes à la place? Si vous n'êtes pas séparer les préoccupations correctement, vous pouvez peut-être pour des maux de tête plus tard.

Answer 5

Pour une logique complexe au sein d'une classe, j'ai trouvé privé méthodes statiques utiles lors de la création isolé logique, dans laquelle l'instance entrées sont clairement définis dans la signature de la méthode et en aucun cas, les effets secondaires peuvent se produire. Toutes les sorties doivent être via la valeur de retour ou/ref paramètres. Briser la logique complexe dans des effets secondaires sans les blocs de code peut améliorer le code de la lisibilité et de l'équipe de développement de la confiance en elle.

D'autre part, elle peut conduire à une classe polluée par une prolifération de méthodes de service. Comme d'habitude, la logique de dénomination, de la documentation et de l'application uniforme de l'équipe des conventions de codage peut atténuer ce.