It seems that Singleton from all design patterns is the most controversial one and people have drastically different views on whether or not it is useful. Many think it is in fact an antipattern and it does more harm than good. Personally I am not a big fan of singletons and it seems to me that 90% of them are just created in a ‘pattern fever’ and complicate or endanger the code. On the other hand I do see that in some situations they can be really useful.

Because of that controversy before giving any actual code in this post I will try to give some reasons why it is good to avoid using this pattern, or in other words: “How a Singleton can ruin your whole day”.

Reason 1: Testability.

The main problem with using singletons is that it is really hard (and sometimes impossible) to test the code that uses them. Imagine a method user.addFriend(User u) in your ‘Facebook-like’ application that adds a new friend to a given user by accessing the database and modifying user’s friends list. If object handling database transactions is a singleton and it is accessed directly in the body of addFriend() then you have no way of writing a unit test for this method without accessing the database! Of course you can try to hack trough this problem, but this quickly will make your code impossible to deal with.

Reason 2: User visible state.

It’s fine for your singleton to have a state, but it can be deadly for you if that state is visible to the singleton user. If it is, then basically you have a global variable and almost no control over it! Imagine your singleton object that handles database transactions has user-visible setDbSettings() method. You set what database you want to write to, get the data you want to write, execute a ‘write statement’ and… nothing happens! Why? What if the method that helped you get the data to write changed your DB settings? What if other thread did that?

Even if your singleton has no state you are in danger: what if in the future some junior developer will decide that is ‘easier’ for him just to add a state to your singleton? Well, basically it is you who gave him the opportunity to do so by creating the singleton in the first place…

Reason 3: Modifiable reference.

Even when your singleton object has no state you may be still dealing with ‘global variable’ problem. Imagine that the reference to your singleton object is modifiable and that someone ‘just for testing purposes’ switches between the production singleton and a mock one? I mention this issue because recently I had the pleasure of fixing a bug that was introduced this way… it’s a really nasty thing to investigate.

Reason 4: Thread synchronization.

When you decide to create singleton you often have to deal with many threads accessing it. Well, you might say that’s not a problem – just add synchronization! Well, that is true, but that also gives you an opportunity to introduce new bugs to the code, the ones that are caused by concurrency and are really hard to fix. Writing synchronization for a large object can be really tricky. If you have already objects like that in your code run FindBugs against them! FindBugs can find some of synchronization errors and believe me that there are plenty of those to go around. Even if you’re sure of your own code have in mind that a month from now some intern or junior developer can make a ’small change’…Is it worth to risk?

I agree that you can minimize risks shown above and that there are coding problems that can be easily solved by using singleton. But then again ask your self a question: do I really need a singleton? Do I really need to have only one object of this class? Many times you’ll get the same result by using injection trough constructor or by using other technologies (guice).

If you still want to write a Singleton check out one of the next posts: I will show the easiest (and the safest) way to do that!