En quête d’un micro framework pour un petit projet, il m’est arrivé plusieurs fois de tomber sur des projets ne regroupant QUE des classes statiques. Du coup, ça m’a donné une idée de sujet : Pourquoi je ne les aime pas 😉

Qu’est ce que c’est ?

Pour mémoire, une classe statique est une classe qui n’utilise que des méthodes statiques. En voici un exemple :

Rien de bien compliqué, à noter l’utilisation de static devant les méthodes, l’opérateur de résolution de portée  :: pour les appeler, et l’absence totale de $this.

En quoi c’est mal ?

En regardant ce (simple, c’est vrai) code, 2 choses me saute aux yeux :

Couplage fort

Par habitude, dès que j’entrevois des classes utilisées exclusivement en service statique, je me dis : « Encore un truc impossible à faire évoluer ». Pourquoi ? Prenons un exemple un peu plus évolué avec un Router :

L’utilisation d’un service statique pourrait être adaptée car on a généralement pas besoin de plusieurs instances d’un Router, une fois le callback effectué on en a généralement plus besoin. En revanche, ce qui est remarquable ici c’est la forte dépendance de nos classes URI et Router.
Si l’on voulait implémenter un autre router, il faudrait impérativement modifier la classe URI et le code applicatif.
Pas génial hein ?

Procédural

Le code plus haut vous semble bien ? Pourtant, ce n’est pas du Orienté Objet. C’est du procédural déguisé..
Je n’ai rien à reprocher au procédural bien sûr, mais dans ce cas inutile de masquer ce code en pseudo-objet.

De plus ici, nos classes URI et Router sont utilisés comme des variables globales, ou chaque modification est définitive (puisque le service statique ne permet pas de créer d’instance).

Jamais jamais ?

Personnellement, je ne les utilise que très très rarement. Je m’assure avant tout que la classe en question n’a pas besoin d’état ni de contexte, et qu’elle soit complètement autonome.

On pourrait par exemple implémenter une simple classe de calcul :

Autrement dit, j’utilise les services statiques comme des fonctions globales..

Brièvement..

Je terminerai par un point à ne pas négliger non plus : les tests.
Un service statique est souvent difficile à isoler, ce qui rend ces classes particulièrement difficile à tester, encore plus lorsqu’elles s’appellent mutuellement.

Pour conclure

Je ne dis pas qu’il faut surtout ne pas utiliser les classes statiques, mais avoir un peu de recul et se demander si cela ne va pas créer de dépendance, si une évolution ne nécessitera pas une refonte complète de la classe, avant d’implémenter un service statique.