Singleton usage

Published 11-24-2006 7:52 PM | jokiz

We currently have a Singleton class in our application which in the next phase of development will change to a multi-instance.  The problem is every class which makes use of it accesses it directly through the exposed static interface.  I believe this is a violation of "Push don't pull" law of Jeremy Miller.

I am not an expert in coding but I believe the said change could have been easier if the dependent classes are not aware about the the Singleton class being a singleton.  They should only be interacting with an instance of the Singleton class.  For dependencies like this, i always design them as much as possible to be injected to the dependent class' constructor.

A good example are some classes which are dependent on configuration settings.  I always provide an abstraction layer between the said class and the config files by providing a wrapper class for the configuration settings.  This way, i can have a Unit test project without a config file which is the ideal setup in my opinion.

Filed under: ,

Comments

# cruizer said on November 24, 2006 9:40 PM:

agree with you jokiz. die singleton die! :P

# Monkeyget said on December 3, 2006 10:01 AM:

The most common criticism made to Singleton is that there is only one instance that everybody shares it and when the need for multiple instance arise you're screwed.

To me the real biggest problem is, as you mention, the fact that everybody call it directly; making it a mess to refactor code.

What you can do to minimize this problem is that when you think you need a singleton, use the factory pattern instead! Implement the singleton class (the class with the only instance) without singleton awareness and instead make sure the factory always return the same instance.

This way the methods needing the singleton cancall the factory and the singleton class which is returned does NOT implement any singleton code!

Later on you decide you want multi-instance? No problemo just add a method to the factory which return a new instance every time.

Another cool stuff if you do that is to use an interface instead of a concrete class. That way, if some day you decide to change the implementation you can do it without changing a single line of the code using the singleton! Just change a few line in the factory and you're set!

At also allows you to choose which implementation use at compile time or even at runtime.

The drawback of this is that it's much more code and more complicated and that you risk to have multiple instance if some code uses directly the singleton class and bypass the factory.

To take your application configuration imagine that instead of creating a simple class wrapping the config file you start to create an interface for it, then a factory to access it,... ugh!

Excuse me for this long comment but your blog entry remembered me of this and i formalised my thinking by writing here.

I should really open a blog to put these kind of stuff instead of abusing people comment system :) .

# jokiz said on December 5, 2006 7:43 AM:

thanks for the rather long comment monkeyget, i appreciate it. having a factory for the singleton is a good idea and a cleaner way to put it. interfaces has proper place for me and i love them for ideal "unit" testing. i actually had an interface for the application configuration for my last project.