8
septembre
2009
Pourquoi je n’aime pas les singletons
septembre
2009
Un article de Philippe Vialatte
Suite a un échange assez long sur le forum, je profite de cet espace de liberté pour crier ma haine du design pattern le plus sur-utilise qu’il soit, a savoir le Singleton…
Pourquoi je n’aime pas le Singleton:
- Parce qu’ils rendent les tests unitaires plus difficiles
- Parce qu’une fois qu’une classe utilise un Singleton, elle est liée fonctionnellement au Singleton, dans le sens ou elle est codée dans l’esprit de consommer un singleton
- Parce qu’un Singleton n’est pas extensible
- Parce qu’une fois qu’on se rends compte que le Singleton n’a pas de raison d’être unique, il est difficile de changer le design
- Parce que le Singleton est un patron de conception avec un but bien défini, et qu’on ignore souvent ce but pour en faire un genre de « classe globale »
En général, lorsque la discussion sur les Singleton revient, cela concerne les points suivants :
- L’accès aux bases de données. Les développeurs pensent créer une seule connexion a la base, et la laisser ouverte. Or, en .Net (et, je pense en d’autres langages), une connexion a la base de données et un objet « précieux », dans le sens ou on a un nombre limite de connexion a disposition. Il faut les rendre au pool des que l’on ne s’en sert plus, et pas chercher a les garder ouvertes, au risque de locker la base de données. Encore pire, dans le cas d’un environnement web (donc multi-utilisateur), sui on restreint l’accès a la base a un utilisateur a la fois, c’est la cata. Solution: créer une classe d’accès aux données qui sera instanciée a la demande.
- L’optimisation. Le point *peut* être valide, et c’est une des deux utilisations « raisonnables » des Singletons. Malheureusement, la plupart du temps, c’est de l’optimisation prématurée. Solution: garder le design propre, sans ajouter une verrue « pour optimiser ». L’optimisation, c’est a la fin (a moins d’avoir un goulot d’étranglement tellement évident que ce serait une faute professionnelle de ne pas le faire
) - Une classe globale. Une classe globale, en soit, c’est pas top. L’état de la classe est partage par toute l’appli, et on est vulnérable aux effets de bord. Une classe utilitaire statique, passe encore, mais le singleton n’a a mon avis, rien a faire dans ce contexte.
En quelques années d’expérience, je n’ai rencontre qu’un seul « vrai » Singleton, et c’était un cas d’optimisation, avec une génération de clé unique assez couteuse. Tous les autres cas de Singletons ont été, a un moment ou un autre de leur existence, remplaces par un autre mécanisme (classe utilitaire, injection, ou autre)
…Par contre, j’aime bien les brocolis, mais ca n’a pas aucun rapport
3 Commentaires + Ajouter un commentaire
Articles récents
Archives
- janvier 2014
- septembre 2013
- août 2013
- mai 2013
- avril 2013
- janvier 2013
- août 2012
- juin 2012
- mai 2012
- avril 2012
- mars 2012
- novembre 2011
- septembre 2011
- août 2011
- juillet 2011
- juin 2011
- mai 2011
- avril 2011
- février 2011
- janvier 2011
- novembre 2010
- octobre 2010
- septembre 2010
- août 2010
- juillet 2010
- juin 2010
- mai 2010
- avril 2010
- mars 2010
- février 2010
- janvier 2010
- décembre 2009
- novembre 2009
- octobre 2009
- septembre 2009
- août 2009
- juillet 2009
- juin 2009
- mai 2009
- avril 2009
- mars 2009
- février 2009
- janvier 2009
Le pauvre, il se fait attaquer et il est tout seul ;o)
Comme je suis d’accord avec certaines remarques, je ne lui serai pas d’un grand secours.
Je peux juste dire qu’à l’inverse, je n’aime pas des classes avec des méthodes statiques qui jouent le rôle de singleton, je n’ai alors plus l’impression de faire de l’objet.
Pour les tests unitaires (1), chaque classe utilisant le singleton écope d’une référence au dit singleton, ce qui rends plus difficile des tests en isolation. Si on a un bug dans le singleton, potentiellement tous les tests utilisant le Singleton vont crasher. En plus, si on veut tester le Singleton, il va probablement falloir un moyen de le resetter -> verrue dans l’API, et on perds 50% de l’interet du singleton
(2 et 4) ok, la, je ne sais plus ce que je voulais dire ;)…bon, plus sérieusement, ca revient au problème de couplage, et au fait que dans 80% des cas, on se retrouve avec un singleton qui en fait n’en est pas un, parce que le gars qui a code venait de lire le livre du GoF
Pour le 3, je parlais de l’extensibilité par héritage, c’est sur que si on cache le Singleton derrière une Factory…Ceci dit, a ce moment la, on utilise une Factory plus qu’un Singleton
> Le singleton doit servir pour offrir un accès UNIQUE à un objet, dont l’état peut éventuellement varier au cours de l’application.
Oui, mais pas seulement, il doit interdire toute création d’un second objet identique dans l’application et dans ses clients. Sinon, c’est une classe globale
> Bref ce n’est pas le singleton qu’il faut hair, mais son utilisation abusive pour tout et n’importe quoi…
Je sais, mais ca marque plus de dire « j’aime pas les singletons » que « j’aime pas quand on se sert pas des Singleton comme il faut »
Salut,
Je ne suis pas forcément d’accord avec toutes tes remarques… mais il est clair que le Singleton est vraiment trop utilisé, pour tout et n’importe quoi !
Concernant tes 5 points :
Le singleton doit servir pour offrir un accès UNIQUE à un objet, dont l’état peut éventuellement varier au cours de l’application.
Dans une application Desktop j’aime bien utiliser cela pour y référencer ma fenêtre principale et son contrôleur, afin de pouvoir centraliser les actions.
Dans une application Web/Serveur, on pourrait l’utiliser pour référencer un cache ou tout autres éléments partagés par tous les utilisateurs… en prenant bien garde aux problèmes de synchronisation !
Bref ce n’est pas le singleton qu’il faut hair, mais son utilisation abusive pour tout et n’importe quoi…
a++