Original link: http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
Although I did not write this article, I completely agree with the views in the article. Brian Button is probably one of the most talented people I know. I'm sure he'll love your feedback.
1. The singleton pattern is often used to provide a global access point for certain services
Yes, you can do this, but at what cost? As we all know, the singleton pattern provides a global access point to certain services in your application so that you don't have to pass a reference to the service everywhere. How is this different from a global variable? (Remember, global variables are bad, right?) What ends up happening is that the dependencies in your design are hidden in the code and cannot be inspected through the interfaces of your classes and methods. What you see. You have to examine your code to know exactly what other objects are used in your class. This may be unclear (Translator's Note: I don't know if this is the translation, original text: This is less clear than it could be). Impulsively creating something global to avoid passing it around is a stench in your design. This is not the function of global variables or singletons. If you examine your design more carefully, you can almost always think of a better design that doesn't have to pass "stray data" around to every object and method.
2. The singleton pattern allows you to limit the number of objects you create
This is also true, but now you are mixing two different responsibilities into the same class, which violates the single responsibility principle of. A class should not care about whether it is a singleton, it should only care about its business responsibilities. If you want to limit the instantiability of certain classes, create a factory or object generator that encapsulates creation and limits the creation ability as you wish, so that the creation responsibilities are separated from the business entity responsibilities.
3. The singleton pattern promotes tight coupling between classes
A basic attribute that makes code testable is that it is loosely coupled to its surrounding environment. This property allows you to replace alternate collaborators during testing in order to achieve specific test goals (think mock objects). The singleton pattern tightly couples the exact type of the singleton object, and loses the opportunity to use polymorphism to replace it. A better option, as discussed in the first point above, is to change your design to allow you to pass object references into your classes and methods, which can alleviate the coupling problem mentioned above.
4. The singleton mode always saves the last state during the continuation of the program
Persistent state is the enemy of unit testing. One of the things that makes unit testing effective is that each test must be independent of all other tests. If this is not the case, then the order in which the tests are run will affect the results of the tests. This can cause tests to fail where they shouldn't, or even worse, cause tests to pass simply because of the order in which they were run. This can hide bugs and be nefarious. A good way to prevent state from being carried from one test to another is to avoid using static variables. The singleton pattern, by its very nature, relies on holding an instance in a static variable. This is a challenge in testing dependencies and can be avoided by passing references to objects into your classes and methods.
Hope this article more or less explains my views on the singleton pattern. I have a small collection of links that I found on Google or elsewhere, including Jim Hyslop and Herb Sutter, who also share these sentiments. If you like them then let me know.
For more articles, please follow my personal blog: http://www.nomoneynowife.com
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
