agree with you jokiz. die singleton die! :P

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 :) .