Testing
One reason is that singletons aren't easy to handle with unit tests. You can't control the instantiation and by their very nature may retain state across invocations.
For that reason the principle of dependency injection is popular. Each class is injected (configured) with the classes they need to function (rather than derive via singleton accessors) and so tests can control which dependent class instances to use (and provide mocks if required).
Frameworks such as Spring will control the lifecycle of their objects and often create singletons, but these objects are injected into their dependent objects by the framework. Thus the codebase itself doesn't treat the objects as singletons.
e.g. rather than this (for example)
public class Portfolio {
private Calculator calc = Calculator.getCalculator();
}
you would inject the calculator:
public class Portfolio {
public Portfolio(Calculator c) {
this.calc = c;
}
}
Thus the Portfolio
object doesn't know/care about how many instances of the Calculator
exist. Tests can inject a dummy Calculator
that make testing easy.
Concurrency
By limiting yourself to one instance of an object, the options for threading are limited. Access to the singleton object may have to be guarded (e.g. via synchronisation). If you can maintain multiple instances of those objects, then you can tailor then number of instances to the threads you have running, and increase the concurrent capabilities of your codebase.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…