Why is Singleton mode evil? _ PHP Tutorial

Why is the singleton mode evil ). Original article: blogs. msdn. combscottdensmorearchive20040525140827.aspx although I did not write this article, I fully agree with the point in this article. BrianButton may be my original article link: http://blogs.msdn.com/ B /scottdensmore/archive/2004/05/25/140827.aspx

Although I did not write this article, I totally agree with the point in this article. Brian Button may be one of the most talented people I know. I believe he will like your feedback.

1. the Singleton mode is often used to provide a global access point for some services.
Yes, you can, but what is the price? As we all know, the singleton mode provides global access points for some services in your application, so that you do not have to transmit a reference to this service everywhere. What is the difference between this and a global variable? (Remember, global variables are not good, aren't they ?) What will happen in the end is that the dependency in your design is hidden in the code. this dependency cannot be seen by checking the interfaces of your classes and methods. You must check the code to know exactly which other objects are used in your class. This may be unclear (Translator's note: I don't know if This is the case for translation. Original article: This is less clear than it cocould be ). Create a global thing with an impulse to avoid passing on it as an odor in your design. this is not a global variable or a singleton function. If you examine your design more carefully, you can almost always think of a better design that doesn't have to pass "wandering data" around to every object and method.

2. Singleton mode allows you to limit the number of objects you have created
This is also true, but now you have mixed two different responsibilities into the same class, which violates the single responsibility principle. A class should not care about whether it is a singleton, but its business responsibilities. If you want to restrict the instantiation capability of some classes, create a factory or object generator that encapsulates the creation and limits the creation capability as you wish, in this way, the responsibilities are divided from the responsibilities of the business entity.

3. Singleton mode promotes tight coupling between classes
Code is a basic property that can be tested. it is loosely coupled with the surrounding environment. This attribute allows you to replace the standby partner in order to achieve specific test goals (think about simulated objects) during the test process. In Singleton mode, the exact type of the singleton object is tightly coupled and the replacement with polymorphism is lost. A better choice, as discussed in the first point above, is to change your design so that you can pass object references to your classes and methods, this can reduce the coupling problem.

4. the Singleton mode keeps the last state in the program's continuous process.
Persistent state is the enemy of unit testing. One thing that makes unit tests effective is that each test must be independent of all other tests. If this is not the case, the test execution sequence will affect the test results. This may cause the test to fail where it should not fail. The worse thing is that the test passes only because of the test running sequence. This may hide the bugs and it is evil. A good way to prevent states from being carried from one test to another is to avoid using static variables. In essence, the singleton mode relies on retaining an instance in a static variable. This is a challenge for testing dependencies. you can avoid it by passing object references to your classes and methods.

I hope this article will explain more or less my views on Singleton mode. I have a small link set found from google or elsewhere, including Jim Hyslop and Herb Sutter. they share these points. If you like them, let me know.

For more articles please follow my personal blog: http://www.nomoneynowife.com

Although I did not write this article, I fully agree with it. Brian Button may be me...