* Introduce a global state in the program, hide the dependencies.
* Test-driven development: classes become tightly coupled with the singleton. Need to test the singleton along with the class to be tested initially.
In software engineering,
the singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system. The concept is sometimes generalized to systems that operate more efficiently when only one object exists, or that restrict the instantiation to a certain number of objects (say, five). Some consider it an anti-pattern, judging that it is overused, introduces unnecessary limitations in situations where a sole instance of a class is not actually required, and introduces global state into an application.
The key points here are that a class is only a singleton if all applications treat it exactly the same and if its clients can use the class without an application context.
Don't worry: the code will always tell you what to do. Just listen.
"singletons are unnecessarily difficult to test and may make strong assumptions about the applications that will use them [...] I know where you live anti-pattern [...] Liskov Substitution Principle".
"To decide whether a class is truly a singleton:
* Will every application use this class exactly the same way? (exactly is the key word)
* Will every application ever need only one instance of this class? (ever and one are the key words)
* Should the clients of this class be unaware of the application they are part of?"