Le singleton est un antipaterne.
Alors merci à Abdelrahman pour cette question.
Pourquoi est-ce que je dis que le singleton est un antipaterne ?
Pourtant c'est le premier qu'on apprend.
C'est souvent le premier convoi dès qu'on s'intéresse à ce sujet.
D'ailleurs bien souvent,
on s'arrête là et on croit qu'on a compris des paternes.
C'est bien souvent malheureusement le seul qu'on retient.
Bon ok, il peut être utile.
Mais...
Mais c'est un piège.
Car le singleton est le meilleur ami du spaghetti monster.
Si vous regardez bien votre singleton quand il y en a un sur le projet,
il n'y a pas rien à souvent un qu'un seul.
Qui devient rapidement un espèce de géant fourre-tout.
Une espèce de caverne d'Ali Baba des variables.
On y met des états globaux.
On y met des états locaux.
Enfin plein de trucs qu'on préfère remplacer avec une machine à état.
Vous le voyez quand vous commencez à avoir plein d'attributs bouléens.
Et que ces attributs bouléens dépendent les uns des autres.
Là vous savez que vous êtes mal.
On y met des variables en tout genre disponibles un peu partout.
Bah oui pourquoi s'embêter à instantier les choses,
pourquoi s'embêter à les injecter ?
On les met dans le singleton et tout va bien.
Le vrai problème c'est qu'il prend de plus en plus d'ampleur.
Et puis au moment où vous réalisez que ce n'est pas forcément une bonne chose,
il est trop tard.
Au moment où vous réalisez que vous êtes embourbé dans le spaghetti monster,
la tâche devient immense pour s'en défaire.
Donc vous ne le faites pas.
Vous ne le faites pas parce que vous n'avez pas de test.
Si vous aviez des tests, vous n'auriez pas de singleton.
Ce qui m'amène au deuxième point.
Et là le mot-clé c'est un mot-clé tout simple, couplage.
Pour tester, pour pouvoir tester son code, on a besoin d'un couplage faible.
Parce que si on a un couplage trop fort,
c'est-à-dire une interdépendance entre les objets fortes,
ça devient vite galère à tester.
C'est aussi, et ça tombe bien,
une règle de conception, une règle d'architecture, une règle de design.
Et par essence, le singleton c'est un truc qui introduit
un couplage énorme.
C'est peut-être le couplage le plus fort,
juste après un truc statique.
Tu vas faire comment dans tes tests
si l'objet que tu test dépend dans singleton.
Comment tu vas faire pour venir paramétrer ces états,
pour venir simuler des problèmes ?
Ben tu ne prends pas.
Alors, je vous ai dit, en début, il peut être utile parfois.
Comment bien utiliser le singleton ?
Et bien tout d'abord, il faut le garder spécifique.
Un singleton doit faire, comme tout objet du reste,
une seule chose,
mais de soigner encore plus vigilant sur le singleton.
Et deuxièmement, par pitié, injectez-le.
Ne laissez pas toutes les classes de votre logiciel
être conscientes de ce singleton.
Injectez-le.
Seul celui qui a instanti la première fois le singleton
doit être conscient que c'est un singleton en l'arrigueur.
Mais pas les classes qu'il utilise.
Je te remercie d'avoir écouté ce podcast jusqu'au bout.
Si tu aimes le développement et que tu cherches à t'améliorer,
rejoins-nous sur artisan-developpeur.com.
Je te dis à demain.