Why this matters
Singleton is one of the most misused patterns. When it works: a config manager, logger, or connection pool — one shared instance is genuinely needed. The trap is using Singleton as a shortcut for global state. The instance becomes invisible coupling: every class that calls getInstance() is secretly coupled to the concrete class, and tests cannot substitute a fake without monkey-patching.
Singleton es uno de los patrones más mal utilizados. Cuándo funciona: un gestor de configuración, logger, o pool de conexiones — genuinamente se necesita una instancia compartida. La trampa es usar Singleton como atajo para el estado global. La instancia se convierte en un acoplamiento invisible: cada clase que llama a getInstance() está secretamente acoplada a la clase concreta, y las pruebas no pueden sustituir un doble sin monkey-patching.
Thread safety and Python modulesSeguridad en hilos y módulos Python
In Python, modules are singletons by default — importing the same module twice returns the same object. A module-level instance is the idiomatic approach. In TypeScript, ES modules behave the same way. Before reaching for a Singleton class, ask whether a module-level constant already solves the problem.
En Python, los módulos son singletons por defecto — importar el mismo módulo dos veces devuelve el mismo objeto. Una instancia a nivel de módulo es el enfoque idiomático. En TypeScript, los módulos ES se comportan igual. Antes de usar una clase Singleton, pregúntate si una constante a nivel de módulo ya resuelve el problema.
💡 Key takeaway
If your Singleton makes unit tests require real infrastructure, it has become an anti-pattern — inject the dependency instead so callers and tests can both supply what they need.
Si tu Singleton hace que las pruebas unitarias requieran infraestructura real, se ha convertido en un antipatrón — inyecta la dependencia para que los llamadores y las pruebas puedan suministrar lo que necesitan.