Singleton es un patrón muy muy enseñado, y creo que es solo porque es fácil de implementar.
Pero este patrón nació en entornos no concurrentes y en procesos de desarrollo que no se utilizaba unit test. Por lo tanto, en ese entorno era bueno, pero el tiempo ha pasado y cada vez más todos los entornos son concurrentes y es imprescindible tener unit test en nuestro software. Lo que ha convertido al amigo Singleton en un Anti-Pattern.
Por que no deberíamos utilizar Singleton:
- Que es singleton: El mayor problema con el patrón singleton (y por qué es, por lo tanto, un antipatrón de diseño en lugar de un patrón de diseño) es que la suposición de que alguna vez habrá solo una instancia a menudo se rompe durante la vida útil de un proyecto, y este patrón se estructura el código de una manera que requiere un esfuerzo muy significativo para refactorizar cuando esta suposición es inevitablemente incorrecta. Es decir, muchos casos demuestran la necesidad de garantizar que el código sea flexible en caso de que la suposición de unicidad resulte falsa, y este patrón hace que el código sea inflexible.
- Dificulta las pruebas: Además de hacer que el código sea inflexible, el patrón singleton también dificulta mucho la prueba del código. Esto se debe a que el patrón singleton introduce una dependencia a través de un canal lateral que no se da explícitamente como parámetro a los constructores u otras funciones que lo utilizan. Incluso en el caso de que este canal lateral pueda ser reemplazado (y a menudo hacerlo es muy difícil), la necesidad de hacerlo es menos obvia y hace que las pruebas sean muy difíciles de entender. El otro problema es que se muy difícil de hacer un mock de este objeto.
- No es seguro a nivel de hilos o es un cuello de botella: Incluso ignorando los problemas anteriores (que son, creo, las razones más fuertes para evitar este patrón), el patrón singleton es especialmente difícil de implementar correctamente cuando se tiene en cuenta el subproceso múltiple. la aplicación requiere que el objeto singleton, en sí mismo, sea seguro para subprocesos; sin embargo, mover la propiedad singleton fuera del objeto permite crear implementaciones alternativas, algunas de las cuales son seguras para subprocesos y otras que no lo son, lo que permite a las aplicaciones que no son multiproceso crear instancias de una versión del objeto que no tiene la sobrecarga de la sincronización de subprocesos al tiempo que permite que las aplicaciones multiproceso creen una instancia de la versión segura para subprocesos.
Si tienen más curiosidad dejo link: https://www.michaelsafyan.com/tech/design/patterns/singleton
