As I mentioned in my previous post regarding the singleton pattern I've seen a lot of talk on different blogs/forums regarding the evils of the singleton pattern. I've tried to cover the general concepts of where this pattern should be used and where it should be avoided in the previous post I made regarding this issue (read here) and in this post I'm going to quote a couple of the stuff that I've found and post my reply to them in here. So here goes: My responses in bold.
The items that I found on http://c2.com/cgi/wiki?SingletonsAreEvil
- Someone had mentioned that when you use the singleton pattern you suddenly have two types of objects:
"those that can be instantiated in a standard fashion and those that cannot be created at all. I would personally rather use a container which governs the number of a given object that can exist in a system and acquire the objects from the container"
We already have a lot of different types of objects that can be instantiated (or not instantiated) in different ways this isn't a particular problem with the singleton pattern but quite the opposite, the singleton pattern is using one of these different types of language mechanisms to obtain what its aiming for (the fact that no one should be able to instantiate the object unless they go through the single point of access). As an example we have interfaces, abstract classes, sealed classes, protected & private constructors, static classes and a whole lot of different types of classes that some you can instantiate in the regular way (using new) and some you can't (and some you are not allowed to instantiate period; e.g. the abstract class). Anyway this isn't a really good argument against the use of the singleton pattern.
- Someone else had mentioned this:
"Singletons usually are used to provide a single point of access to a global service. I always make the singleton separate from the class itself so the class can be used any way you want. The singleton can then use the class. The singleton also doesn't have to instantiate the object"
One of the points of the singleton pattern is to prevent accidental or purposeful creation of the singleton object, that's why it has a private constructor so one can create it except for the singleton class itself which knows when and where to create it. In regards to the second part I have seen C++ code that uses the "friend" keyword to have a separate singleton factory than the singleton object itself but I really can't see any use for it. You need a single point of access you also need a class that can be instantiated in a controlled manner why are you making your design complex and the programmer using your design confused by making him deal with (and understand) two classes (albeit one being very small and simple). I guess you might come up with very rare cases where this would be useful but in general I think sticking with a singleton class that also provides the single point of access is the best way to go.
- A couple of people where mentioning coupling issues with singleton class names and/or polymorphism issues with the singleton:
"Subsystem's coupling to Singleton's Class Name" or "Singletons aren't polymorphic"
Let's make something very clear singletons are polymorphic (please read the section regarding polymorphic singletons in this post) and let's also focus on something else the whole reason we are using a singleton as opposed to a global variable (or static member) is because it allows us to deal with the single point of access issue through an object oriented fashion. It allows us to have all the OO design techniques, design patterns etc. at our disposal when we are dealing with a singleton just as we would when dealing with other classes & objects. So all general OO design techniques and features apply to a singleton.
Regarding the first argument: your different subsystem's are going to be dependent on some single point of access (because you've made that design decision) now it's a lot better that you implement it using the polymorphic singleton pattern just to make sure that they are only dependant on an abstract class (the singleton being that abstract class) not on the actual implementation.
- An amusing one:
"Doesn't a C# static class, with its static constructor, provide all the functionality you would ever need from a singleton?"
OK I think this guy has missed the whole point of the singleton. If you use a static class that means all member variables/methods are static and then you might use the static constructor to initialize some of these member variables, BUT this isn't object oriented programming this is a feature simulating the procedural way of design & implementation. Why have the designers of the C# language decided to include it there? Well one reason being the fact that you will need utility classes (methods) that are pure static classes and you don't need a real object to respond to the calls (another design decision) but a utility (or pure static class) is just a bunch of methods but a singleton is a full blown object instantiated from a class the only difference being that only one instance (or a limited number of instances) exist of it.
If you think this argument is correct you should try to first understand the singleton pattern and then come back and re-read what the argument is saying!
These items I've found on http://www-128.ibm.com/developerworks/webservices/library/co-single.html
- "There is one implementation anti-pattern that flourishes in an application with too many singletons: I know where you live anti-pattern. This occurs when, among collaborating classes, one class knows where to get instances of the other."
This will be a problem when you overuse the singleton pattern, but correct usage of the pattern especially in places where there is a strong domain reason or a legitimate technical requirement backing its existence but otherwise over-use of the pattern will cause the above mentioned problem.
- "Where's the harm? Coupling among classes is vastly increased when classes know where to get instances of their collaborators. First, any change in how the supplier class is instantiated ripples into the client class. This violates the Liskov Substitution Principle, which states that you should allow any application the freedom to tell the client class to collaborate with any subclass of the supplier. This violation is felt by unit tests, but more importantly, it makes it difficult to enhance the supplier in a backward-compatible way. First, the unit tests cannot pass the client class a mock supplier instance for the purposes of simulating the supplier's behavior, as described above. Next, no one can enhance the supplier without changing the client code, which requires access to the supplier's source. Even when you have access to the supplier's source, do you really want to change all 178 clients of the supplier? Weren't you planning on having a nice, relaxing weekend?
Collaborating classes should be built to allow the application to decide how to wire them together. This increases the flexibility of the application and makes unit testing simpler, faster, and generally more effective. Remember that the easier it is to test a class, the more likely a developer will test it."
Again I think this a case of misuse of the pattern. Let's straighten one thing out the fact that a singleton is a class that by default you're not suppose to instantiate doesn't mean that it can't have sub-classes and doesn't mean that replacing it with "stub" classes for the purpose of testing would be impossible. I feel I'm repeating myself too much but a polymorphic singleton especially when it's combined with other patterns such as bridge or strategy it can give you all the flexibility in the world and doesn't affect testing or any other type of pluggable behavior. Completely loosely coupled!
- "To decide whether a class is truly a singleton, you must ask yourself some questions: (1) Will every application use this class exactly the same way? (exactly is the key word) (2) Will every application ever need only one instance of this class? (ever and one are the key words) (3) Should the clients of this class be unaware of the application they are part of?"
I don't agree with the rules set above although they might be very helpful in situations where there is going to be only one instance of the singleton but as Gamma mentions in his book a singleton might be polymorphic (therefore question 1 is not really the case if you need a polymorphic singleton), a singleton might be designed because we need a controlled number of objects (therefore question 2 is not true) and I don't understand question 3! J
This item is from http://www.sitepoint.com/forums/showthread.php?t=386447
- "It's hard coupling. Singletons are essentially static functions - the difference is syntactical sugar. Whenever you reference a static symbol in your code, you make it more dependent on the context. It's really the same as with a global variable - A global variable is bad because it has a global scope. A static function is also global in scope, so it has the same problems associated. The difference between the two, which accounts for the assumption that singletons are slightly better than global variables, is that functions are more abstract than variables, and this gives you some flexibility. This flexibility can then be used to excersise some damage control. Still it can't beat narrowing the scope, which is what objects provides."
Hard coupling!! First time I heard that (I think he meant tight coupling). Anyhow this description is very good, and especially relevant to misuse of the pattern. If you use a singleton as an excuse to be lazy and not think about your design, if you use a singleton as an excuse to make everything global then yes there is no difference between a singleton and static members BUT if you use the singleton where it's supposed to be used it will be a whole lot more than "syntactical sugar." Plus we are forgetting that part of using a pattern isn't just because it's implemented with for example a static member or it isn't, but it's the whole knowledge that comes packed up with a pattern and is transferred to the next person (read this post). The above comparison is like saying using functions & procedures is "syntactical sugar" to using a goto statement because they are eventually a jump to a piece of code and a jump back! But that's not the case, functions and procedures provide a higher level of abstraction, so do classes, interfaces etc. which provide an even higher level of abstraction. Patterns are pretty much the same thing they too provide a higher level of abstraction albeit being implemented using mundane "static" members or similar constructs of a lower level of abstraction.
Items from http://home.earthlink.net/~huston2/dp/singleton.html
- "It's relatively easy to protect Singleton against multiple instantiations because there is good language support in this area. The most complicated problem is managing a Singleton's lifetime, especially its destruction ... There are serious threading issues surrounding the pattern."
Who says we don't want multiple instantiation of a singleton? There are cases that we need multiple instantiation (but controlled number of instances). I totally agree that in C++ and other languages that don't have garbage collection managing the lifetime of a Singleton or a lot of other patterns could be hard but not impossible. Yes threading could also be a serious problem to consider, but with singletons there are usually two scenarios that occur: you either have a singleton instance per thread then you have a multi-instanced singleton which returns an instance based on the calling active thread or you have on instance of the singleton replying to all threads which means the class must be thread-aware.
- "The Singleton design pattern is one of the most inappropriately used patterns. Singletons are intended to be used when a class must have exactly one instance, no more, no less ... frequently use Singletons in a misguided attempt to replace global variables ... A Singleton is, for intents and purposes, a global variable. The Singleton does not do away with the global; it merely renames it."
One instance and no more? I don't agree and if you read Gamma's book you'll see that it's not what he intended when he created the pattern. I agree that singleton is usually misused and it is not supposed to fix global variable problems (i.e. common coupling) but the advantages it provides as opposed to using a global variable are tremendous. Read my post on this issue here & here.
"When is Singleton unnecessary? Short answer: most of the time. Long answer: when it's simpler to pass an object resource as a reference to the objects that need it, rather than letting objects access the resource globally ... The real problem with Singletons is that they give you such a good excuse not to think carefully about the appropriate visibility of an object. Finding the right balance of exposure and protection for an object is critical for maintaining flexibility."
I agree completely! Very well said.
- "Our group had a bad habit of using global data, so I did a study group on Singleton. The next thing I know Singletons appeared everywhere and none of the problems related to global data went away. The answer to the global data question is not, "Make it a Singleton." The answer is, "Why in the hell are you using global data?" Changing the name doesn't change the problem. In fact, it may make it worse because it gives you the opportunity to say, "Well I'm not doing that, I'm doing this" – even though this and that are the same thing."
Very well said.
No comments:
Post a Comment