Discussion :

[Rodie]

Bonjour,

J'ai eu un petit débat avec mon supérieur qui me reproche d'utiliser le mot "static" pour toutes mes méthodes.
En fait, dans ma tête, dès qu'une méthode ne dépend pas d'un objet en particulier et ne fait que retourner qqch en fonction de ses input, je la mets en "static".
Par exemple, je mettrais en static des méthodes qui :
- ajuste la largeur d'une combobox en fonction de son contenu
- renvoit un Dataset à partir d'une requête SQL
- renvoit un TreeNode[] à partir d'une requête SQL
- instancie et renvoit un datagridview vide
...

En fait, je mets "static" chaque fois que la méthode se comporte comme une librairie et doit être accessible partout.
Mon supérieur me disait alors : "Ouais mais dès qu'on veut rajouter des status, des variables pour modifier le fonctionnement de tes méthodes statiques, bin on peut pas, sauf en passant un tas d'arguments en input de tes méthodes...".

Quelque part, il a raison. Alors si vous pouvez me faire un retour sur tout ça (différence de performance, facilité de codage, maintenance...), ça serait super
Merci d'avance.

[Neitsa]

Bonjour,

En fait, dans ma tête, dès qu'une méthode ne dépend pas d'un objet en particulier et ne fait que retourner qqch en fonction de ses input, je la mets en "static".

C'est la convention "normale" et de facto adoptée chez Microsoft par exemple (au travers des conventions qu'ils utilisent en interne et qui ont été inscrites dans des outils comme FxCop).

Toute méthode n'ayant pas de référence à "this" devrait être déclarée statique.

Et comme le dit cette fois ci la spécification de C#, chapitre 10.5.2 :

A static method does not operate on a specific instance, and it is a compile-time error to refer to this in a static method.

Il en découle que si une méthode n'opère pas sur une instance spécifique, on peut la qualifiée de statique.

Voir à ce sujet la règle dans "Writing quality code" => "Mark Members As Static" :

http://msdn2.microsoft.com/en-us/lib...18(vs.80).aspx

Maintenant il faut garder à l'esprit que c'est une convention et non pas une règle standardisée (sous peine de "fouetage" aux orties fraîches ).

Le problème de déclaration d'une méthode statique (je pense notamment aux cas des bibliothèques) est que si à un moment la méthode doit travailler sur une instance (référence à "this") il y a un "breaking change", ce qui implique que tout les clients doivent changer leur code source...

Si on qualifie une méthode de statique alors il faut se dire qu'elle ne travaillera plus jamais sur l'instance actuelle (this) et que l'on ne reviendra pas sur ce comportement sous peine d'introduire de trop grand changement.

Par contre, marquer une méthode statique peut être fait quand les scénarios de code sont établis, c'est à dire lors de la finalisation du développement.

Au niveau performance (et pratique de codage), comme le souligne D. Kean :

Although this rule is classified as a performance issue, the performance improvement of making a method static is only around 1%.

Rather, it is more a correctness issue that could indicate an either an incomplete or a bug in the member by its failure to use other instance members. Marking a method static (Shared in Visual Basic) makes it clear on its intention not to touch instance state.

Il reste toujours des scénarios possibles ou une méthode ne touchant pas à l'instance peut ne pas être marquée comme étant statique, le plus évident étant une possibilité d'évolution de cette même méthode.

[Rodie]

Coucou

Merci beaucoup pour tes explications !
Effectivement, je prends conscience que les méthodes statiques sont difficilement évolutives. En plus, on code en C# ici, pas en C
Merci pour les liens, je vais m'y intéresser !