So Eric is sort of right although he doesn't explicitly state it: Singletons may provide a decoupling point nearly identical to dependency injection when design

So Eric is sort of right although he doesn't explicitly state it: Singletons may provide a decoupling point nearly identical to dependency injection when designed with care. But that's not really the problem, and he stops with an argument that is compelling to someone in 2002 but not so compelling for someone from 2012. The reason we prefer non-singletons to singletons are as follows: • Most languages do not provide very good ways to prevent singleton collision. As software has become more complex and open source's success increases the size of the average dependency tree, this problem is exacerbated. • Singletons force you to confront all the problems shared state concurrency has to offer, with almost no support. DI objects tend to be isolated from one another and do not run into that level of complexity so soon. • Singletons tend to make it harder to test code unless your language has a method for overriding or mocking singletons within a dynamic scope (or static type checking between types with liskov-substitutable signatures). The most classic exampe of this is one of the most prevalent singletons: your system clock. Knowing what we know now about how successful software projects tend to be confronted with expectations of concurrency, parallelism, robustness in the face of reuse, and testability; singletons offer a lot of costs for very transient benefits.