Singletons are Evil?

There is an article “Why Singletons are Evil” written by Scott Densmore in 2004 aroused controversy. Suggest you to click the link to see what he said before reading this. Recently I found some points in this article has been quoted and recorded in the development guide in our team, which is completed by an experience engineer, with a short section title “Anti-design patterns — avoid use of Singleton”. Seeing this I think I need to analyze and dispute the points.

1. The first point of Scott is, Singleton is used to provide a global access point, but at an unacceptable cost. He even compares singleton with global variable, and the dependencies are hidden inside, which makes the code unclear.

OK, before we really start to talk about singleton, let’s get something clear. When we’re talking about singleton, mostly we have two scenarios, one is we compare a singleton class with a class all the methods and fields of which are static, carrying global and static status, they all supply global access point, and from the function view they are similar; the other is we compare singleton with regular object creation, new object manually or using a factory. Obviously Scott is talking about the latter.

Does singleton hide the dependencies inside the class? True, you just need to get the instance and use it, you don’t know how the object was created, or it’s being created right now. But why is that incorrect? In the software world you cannot and you needn’t to understand everything, that’s why an engineer can focus on his own work. Avoid caring of the object creation, it’s an advantage. Considering the performance cost, we need a single object pattern, and it’s the most intuitive pattern for many abstraction concepts reflecting to the real world.

2. Scott thinks singleton is a violation of the single responsibility principle, in other words, a class should not care whether it’s a singleton.

True again, but we need to achieve balance. How to split object creation from its own business purpose? Use factory, correct, but it’s horrible if every object needs a factory.

3. The third point is, singleton promotes tight couple, obviously recognized in test.

Yes, it’s not as test friendly as a regular class, but it’s still testable. Plus, single object can be polymorphic as well.

4. Singleton carries state that lasts as long as the program lasts, which is the enemy of unit test.

True, but every coin has two sides. Status carrying means the initialization work can be saved. BTW, we sometimes over estimate the cost of being testable. Reset the status of objects before running the test case, it’s not so hard.

These drawbacks cannot prove singleton is an evil or should not be used, on the contrary, it is simple, easy to use and resource saved. Singleton will always be controversial, but just “avoid” it arbitrarily without considering the situation is ridiculous, it’s still being needed, just case by case. Singletons are not evil, but avoiding using singleton has been written in our team’s development guide, that’s evil.

文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》