Question

In almost every project I create a few classes which implement Singleton pattern. For example, data manager – if there’s some work with file system, data loader – if an application connects to the internet, different resources managers, etc. Sometimes there are up to 5-7 such classes and I start feeling that I’m doing something wrong. Is it a bad practice to use Singleton pattern too much?

Answer 1

Singletons are not necessarily problems — having a single object that is an expert in its domain can be very useful — but explicitly coding the singleton-ness into the object is almost always a bad idea (and frequently is done badly too). It turns out that it is better to leave the configuration of the application — including the decision of what classes have singleton instantiations — to a separate layer that specializes in that, such as Spring for Java. Like that, the management layer can look after what is a singleton, what is a singleton within a particular context (e.g., within the scope of a session) and what always needs to be manufactured anew. That leaves you free to focus on writing the business logic.

For an example of why Singletons can be problems and why they should be singletons by management/configuration, consider a class that manages the connection to a database. Classic case for a singleton you might say. You’d be right too, right up until you find that your app has grown to the point where it has to integrate connections to two databases (it happens!) and then you’ve got to disentangle the whole mess. If you’ve kept your code agnostic of whether it is dealing with singletons or not, you stand an excellent chance of being able to handle it all by just reconfiguring; some classes will be connected to one DB and some to the other, but they’ll just get on with it with minimal fuss. (Anything that needs both… well, that’s why I said “excellent chance”.)

Another example of why Singletons can be problems comes when you’re writing tests for your code. (You do write tests, yes?) Explicit singletons are very difficult to test, as they’re hard to configure and hard to isolate. You can’t tear them down properly between tests because that implies having many of them. If your app uses singletons only by configuration, a testing configuration can easily change that and you can do your tests far more easily.