human
Vous trouvez sur internet l'affirmation que les Singletons sont mauvais. Est-ce vrai ? Pourquoi ?
Le problème serait-il généralisé pour n'importe quel objet avec une instance unique ? Ou pour n'importe quoi ayant un état global ?
Si c'est si mauvais, pourquoi a-t-il été inventé ? Autrement dit, quel problème voulait-il résoudre ?
Quels problèmes aurai-je si je l'utilise ?
Existe-t-il une alternative viable
gpt
Une grande partie de la polémique provient du manque de contextualisation. Je ne vois rien qui discrédite le modèle Singleton lorsqu'il est utilisé dans le bon contexte. Oui, il peut causer beaucoup de problèmes, tout comme n'importe quel modèle de conception appliqué de manière incorrecte sans analyse de l'impact et des effets secondaires.

###Pourquoi ne pas l'utiliser
* Couplage. En utilisant un Singleton, vous couplez le code à une implémentation statique et spécifique. Cela rend votre code dépendant de cette classe et empêche, par exemple, la création de mocks dans les tests unitaires. De ce point de vue, la conséquence est essentiellement la même que de faire directement un ```new MonObjetImportant()```, car c'est une dépendance directe de la classe.
* Portée. Le modèle Singleton appliqué selon la définition élimine également le concept de portée. Cela signifie que si, pour une raison quelconque, vous décidez que vous avez besoin d'une autre implémentation pour certains composants de l'application, vous devrez modifier manuellement toutes les classes.
* Pas de garantie d'une instance unique. Dans certains cas, le modèle peut donner une fausse sécurité en pensant qu'il n'y aura qu'une seule instance. Supposons que vous conceviez un système web et que vous vouliez donner accès à un fichier ou une ressource exclusive. Un Singleton semble être une bonne pratique, n'est-ce pas ? Mais que se passe-t-il si demain vous déployez l'application sur un cluster avec N serveurs.

Dans le cas de Java, cela est également très compliqué, car il n'y a pas de notion de classe par JVM. Le concept correct est une classe par ```ClassLoader```, de sorte que sur un même serveur JEE, deux applications différentes peuvent avoir leur propre version de la même classe. Les variables statiques ne sont pas partagées entre ces versions de la même classe, donc la portée du Singleton en Java est par ```ClassLoader``` et non par programme.

###Pourquoi l'utiliser
Dans certaines situations, vous savez qu'il n'y aura qu'une seule instance de la classe. Dans une application de bureau, par exemple, il n'est pas nécessaire de compliquer les choses pour obtenir une connexion à la base de données.
Je ne vois également aucun problème à encapsuler certains attributs de configuration globaux dans un objet. Il ne vaudrait tout simplement pas la peine de mettre en place un mécanisme très élaboré pour quelque chose d'aussi simple.

###Comment l'utiliser
Lorsque nous pensons au Singleton, nous pensons immédiatement à la mise en œuvre classique du Gang des Quatre. Les sujets précédents de cette réponse ont pris cela en compte. Cependant, avec l'avènement de l'utilisation de frameworks d'Inversion de Contrôle (IoC) et d'Injection de Dépendances (DI), il existe aujourd'hui une manière beaucoup plus "sûre" et flexible de mettre en œuvre le modèle: laissez le framework s'en occuper pour vous !

###Comment éviter le Singleton
Bien que des implémentations plus simples puissent utiliser le modèle Singleton de manière "classique" sans problème, il serait généralement préférable d'appliquer l'Inversion de Contrôle et simplement laisser les instances de vos dépendances être injectées. De cette façon, si demain les exigences changent et que vous avez besoin d'injecter différentes instances, ou même si vous souhaitez créer des mocks de test, il vous suffit de configurer votre conteneur ou framework en conséquence, sans modifier les implémentations existantes.