The null singleton

Julien on May 24th 2008

I'll say it straight: I really don't like the Singleton pattern. I think this pattern was great a few years ago, before we started to use things such as dependency injection or dependency lookup. Unfortunately for me, as of today, it's probably the most used pattern in software development. To be fair, this pattern can be useful in several scenarios, but please... not everywhere! (For the record, the a singleton is a pattern that ensures that you have only one instance for a specific class. This instance is created "on demand", the first time the class is used.)

The main problems with singletons are obvious:

  • You don't control when an instance is created, so if you have lot of them you have no idea in which order the instances will be created. Not an issue on small software, but more worrying when you have a few hundred thousands of lines.
  • 99% of the time, the implementation that is used binds us to a specific class. Therefore you have either to refactor the singleton or use a tool like TypeMock if you want to unit test your code. (Or you can have a empty class that holds the static instance and returns it casted as an interface... But doing that results in a multiplication of almost useless classes)
  • Dependencies are not obvious (which can also be a problem with dependency lookup). If you have type A that uses a singleton of type B, nothing in A signature will show you the dependency. It might be a problem if you're not aware that using A results in a hundred of round trips to the database through B!

However, I recently discovered a pattern that is even worse than the Singleton: I call it the "Null Singleton"! It's a very simple concept: the singleton can fail to instantiate itself if some dependency (a config file, a database, or whatever) is not available. In that case, the instance returned by the singleton will be null. Let's see an example:

So what is wrong with that?

  • If the dependency is unavailable, the NullSingleton will check again the dependency each time something will access it. It will probably be very slow (usually, it will be an out of process call).
  • Each time you try to get an instance, you'll have to check for a null reference which makes the code noisy
  • And finally, it's breaking the usual expectation about singletons (that it should return 1 instance)

Do yourself a favor: don't use a "Null Singleton" :-)

kick it on DotNetKicks.com

Filed in General development | 2 responses so far

2 Responses to “The null singleton”

  1. agamemnon May 26th 2008 at 09:49 am 1

    Hello Julien,

    I have few remarks about instance initialization in singleton. Concurrency access and instance creation are often forgotten when using this design pattern. This can lead to the creation of more than one instance (but thanks to the garbage collector if available, only one will be kept).
    The second remark is rather a question. The class instance can be created in class loading time with a static block like this : private static Singleton instance = new Singleton();
    This creation method can solve some extra cost when managing the concurrent access to the instance, but is it safe to use it? (I have some doubts about dll loading order and instances creation).
    You mention the case where we have a large number of singleton. I have noticed in the software I’m working on it is that there is no method to free the instance.

    Regards

  2. Julien May 26th 2008 at 01:50 pm 2

    Multithreading is definitely an issue with singletons: most of the time, the implementation is not thread safe which can result in a “lost” instance as you were saying. Even if garbage collection is there, it can have several nasty effects depending on the context. For instance, the second instance created can try to access something that will be locked by the first instance and then fail to instantiate itself properly.

    Concerning your way to initialize the singleton, I think it will be thread safe because a static field is only populated once by the CLR. However, the problem is that the instance will be created as soon something from the class is called for the first time. Therefore, you have even less control on when the instance will be created (but that might be perfectly acceptable :)). Using a static constructor might also be problematic. In that case, the instance will be created when the class is accessed but if an exception happens in the static constructor, it will be rethrown as a TypeInitializationException which would be a bit surprising I guess. More information here.

    Finally, disposing a singleton is not something I’ve seen before and I would even say that it’s probably a code-smell. As a matter of fact, I don’t think you should dispose a singleton during the lifetime of the program. You might want to reset the state of the singleton somehow, but not dispose it. If you need to dispose it before the end of the program, you might end up with dozens or hundreds of initializations of your singleton… it will be totally uncontrolled. If you’re at the end of the lifetime of the program, then it’s not really a big deal because the CLR will release all the resources for you anyway.

Trackback URI | Comments RSS

Leave a Reply