Singletons are not evil
Scott Densmore has an interesting post regarding singletons and why he thinks they are evil. I’d like to go through his points one by one and add my thoughts:
Singletons frequently are used to provide a global access point for some service.
Unfortunately, I tend to agree with this. However, this does not make the Singleton pattern evil. Using a singleton in this way could easily be compared to using global variables. Using a singleton for this is no different than having a class with a bunch of static members on it.
Singletons should be used to control creation, not access. A singleton should *not* be used as a global object just because you can. I find it hard to dismiss a pattern simply because some people dont use it how it was intended to be used.
Singletons allow you to limit creation of your objects.
Scott states that this is true (as it is), but thinks that this is a violation of the Single Responsibility Principle, since a class should only be concerned with its business responsibilities.
Most of the issues around singletons revolve around the terminology. After all, isnt the Singleton property/method *really* just a Factory Method.
I agree that you could use a factory or builder object to do this for you, however, this method doesnt allow you to create one and only one instance.
Singletons promote tight coupling between classes.
This one I have to agree with. The way around this is to use a factory method, however, then you dont get the private constructor that the singleton really should have.
Singletons carry state with them that last as long as the program lasts.
As they should. The idea behind a singleton is that you need one and only one instance of an object.
As with any design pattern, the singleton is good when it is used wisely. Unfortunately, what happens a lot of the time is that a pattern is thrown into something without looking at the other options. Before implementing a singleton is not a bad idea to ask yourself, would it be wrong to have another instance of this class in the system?
Let me leave you with this to chew on… If singletons are evil and should be avoided at all costs, how would you suggest to handle things in the framework such as HttpContext? I personally find HttpContext.Current to be an absolute godsend. Without it, I would probably end up having to corrupt my class interfaces with properties or method parameters that will allow me to access HttpContext.
I have been reading everyone’s input on pattern design and I am soaking it all in. Can someone point me to a good resource that will define these terms (singleton, factory, facade, proxies, etc.) and help me determine the best approach for my project’s design?
It seems to me that people want the Singleton pattern to be or work in a way that is not intended to. This spawns the idea that people use it excessively and in contexts that it should not be used in. Like I tell people, its a tool that has only one purpose. Once you cross the line of that purpose, you are using the pattern in a way it was not intended. For example, if you need an order in which resources are created, don’t use a pattern like this. If you want to have many instances of a singleton, don’t use this pattern. etc.
Once thing that you did not mention here is that This pattern is not thread safe, and this is a fact. But it all depends on what the singleton is used for. If it does not have a state, then there is no state to manage between threads, making that class essentially thread safe. Singletons work best in non-state classes.
Another problem I have run into in my programming career is that not only are they not safe, they are also horrible when compiled into DLLs. A DLL has its own memory space and will create a singleton in its space ONLY. Therefore, any program that uses that DLL and tries to access the singleton will soon find out that the singleton creates another instance of itself in a different section of memory. This is how DLLs were designed.
Those are the only two scenarios where singletons fail. Everything else is a property of this pattern and most likely is the fault of the programmer not using it as intended.
I found this post while googling “httpcontext.current evil” because I think it is. I was looking for tools to hook into my build process that would raise warnings when we use it. I’ll give a few reasons.
1. HttpContext.Current must have thread affinity because multiple IHttpHandlers may be executing concurrently on different threads. Therefore, HttpContext.Current is probably implemented using either a [ThreadStatic] attribute or some other mechanism to limit its scope to the executing thread. There is a considerable performance cost to using these constructs.
2. HttpContext encourages poor separation of concern. In a layered architecture, a Page might call a method on a service class, which would delegate to a data access object, then do some business logic. None of these layers (except the Page) need to know they are executing in a web context. However, it’s all too easy to write HttpContext.Current from anywhere in your code, in any layer, to check for a query parameter or write a cookie, or do any other number of things that you shouldn’t be doing at that point.
Furthermore, you seem to be confused about the nature of HttpContext. HttpContext.Current will return an instance of HttpContext that will be different on each thread. Therefore, it isn’t a singleton at all. Neither is HttpApplication for that matter (though HttpApplicationState is). Head spinning yet?
In the JEE / JSP world, these static/ThreadStatic constructs don’t exist, and I don’t think anyone really misses them.
I’m quite confused with Scott’s and this post.
I think the primary motive for Singleton pattern is to limit creation of the instance. I think point #2 is weak.
Do I really care if it violates the Single responsibility rule? I’d rather allow this than write another factory class just for a single method (at the cost of being labelled an immature designer. I’ve been called a lot of other things). + I too don’t get how I would get the private ctor bit done with Scott’s/Brian’s approach.
If I keep the ctor public - it ain’t unique
if I keep the ctor private - the factory can’t create it
maybe use something like internal in .NET, but then any other class in that assembly can do a new which violates the req. This puts more emphasis on ‘Future coders playing by the rules’