L'auteur explique pourquoi le pattern Singleton, bien que séduisant par sa simplicité, se transforme souvent en antipattern coûteux. À travers son expérience sur un projet legacy truffé de Singletons, il montre comment ce pattern crée des dépendances cachées, rend les tests impossibles et engendre des problèmes de concurrence. Le Singleton, en agissant comme une variable globale déguisée, viole plusieurs principes SOLID (Dependency Inversion, Single Responsibility, Open/Closed) et complique la maintenance du code. Les tests deviennent difficiles à écrire et à isoler, tandis que la gestion de l’état global partagé introduit des bugs aléatoires et des goulots d’étranglement. L’auteur propose des alternatives comme l’injection de dépendances, la composition root ou les factories, qui rendent le code plus testable, flexible et maintenable. Il conclut que le Singleton doit être évité dans la plupart des cas, sauf pour des ressources vraiment uniques et globales, et insiste sur l’importance de bien évaluer les compromis avant de l’utiliser.