Comments on: Singletons are not evil

By: Code

Code — Fri, 15 Aug 2008 18:39:49 +0000

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.

By: Mark

Mark — Mon, 26 May 2008 18:46:32 +0000

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.

By: Brian

Brian — Sat, 19 Apr 2008 18:34:13 +0000

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?

By: Gishu

Gishu — Tue, 22 Nov 2005 11:03:19 +0000

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’