Cela dépend. Il existe réellement 2 types de méthodes statiques :
- Les méthodes qui sont statiques parce qu'elles peuvent être
- Les méthodes qui sont statiques parce qu'elles DOIVENT l'être
Dans une base de code de taille petite à moyenne, vous pouvez vraiment traiter les deux méthodes de manière interchangeable.
Si vous avez une méthode qui appartient à la première catégorie (can-be-static) et que vous devez la modifier pour accéder à l'état de la classe, il est relativement simple de déterminer s'il est possible de transformer la méthode statique en méthode d'instance.
Dans une grande base de code, cependant, le nombre de sites d'appel peut rendre trop coûteuse la recherche pour voir s'il est possible de convertir une méthode statique en méthode non statique. Souvent, les gens verront le nombre d'appels, et diront "ok.... Je ferais mieux de ne pas modifier cette méthode, mais d'en créer une nouvelle qui réponde à mes besoins".
Cela peut aboutir à l'un ou l'autre :
- Beaucoup de duplication de code
- Une explosion du nombre d'arguments de méthode
Ces deux choses sont mauvaises.
Ainsi, si vous avez une base de code supérieure à 200 000 LOC, je vous conseille de ne rendre les méthodes statiques que si elles doivent l'être.
Le refactoring de non-statique à statique est relativement facile (il suffit d'ajouter un mot-clé), donc si vous voulez faire d'une can-be-static une statique réelle plus tard (lorsque vous avez besoin de sa fonctionnalité en dehors d'une instance) alors vous pouvez. Cependant, le refactoring inverse, qui consiste à transformer une can-be-static en une méthode d'instance, est BEAUCOUP plus coûteux.
Avec de grandes bases de code, il est préférable de se tromper sur la facilité d'extension, plutôt que sur la pureté idéologique.
Ainsi, pour les grands projets, ne rendez pas les choses statiques à moins que vous n'ayez besoin qu'elles le soient. Pour les petits projets, faites ce que vous préférez.