::Friends don't let friends write singletons:: [/tech/coding] (01:35)

The question of singleton or static class reminds me that it's time for another rant against the evil that is the singleton anti-pattern. I don't have a problem with the points made, instead I want to again ask why one would ever use a singleton.

Well, because you want to make sure only one instance of an object exists in the system, silly. But why? Why should anyone ever care to enforce a rule that only one instance can exist in the system?

I've yet to see a compelling example of a non-system level case where a singleton was actually required. Normally the real need is simply for cached instance that is easily locatable. The application doesn't actually REQUIRE that only one instance be created. Instead, it simply only wants one instance and using the singleton pattern provides an easy way to do the cached lookup. Most of the time, it doesn't matter (performance and memory issues aside) if multiple instances of the object existed. It's just that the static getInstance() is so easy. And hey, look it's a "Design Pattern", so it must be right.

Of course, the singleton is nightmare to to test. The truth is that most singleton objects depend on context information. (and you have my pity if you have to interact with a singleton configuration context) That context information might be set in stone for a single run of the application. But in testing, you want to have multiple contexts. Good luck trying to get your singletons to do what you want. But, my goal isn't to identify the singleton pain points. (besides, you've probably already felt them yourself)

Instead, I'd like to offer some advice for working without singletons. First, keep in mind what your goals are. If you need a cached instance, then simply provide a cached instance. Don't restrict the usage of your class in ways that aren't absolutely necessary.

Decouple object creation policies from your class. If you have a need to provide for controlled instantion of a class, don't put the logic on the class in a static method. Put that logic in some other place, (think factory or builder) allowing your application to choose/extend/override the creation policy as needed. Let the object worry about providing it's functionality and let some other object worry about managing instances of objects. Mixing the two causes pain.

Avoid hardcoded lookup strategies in your code. Instead of seeing singletons in your design, see managed components. When you see managed components, think about inversion of control. I've tried to avoid jumping on the IoC bandwagon, but the solution is extremely elegant. Instead of having your components do hardcoded getInstance() lookups, let a manager object tell you what the object is. You can still have one shared instance for all your components if you want. But you can do it without the restrictions that the singleton brings.

Avoiding singletons isn't always easy. Singleton's are great replacements for global variables and they keep you from having to create and manage a context for your application. It's easy to choose present conveniece at the expense of future pain, especially when you are following a well known design pattern. After all, if it's in GoF, it must always be a good thing, right? Just think through your goals. There may be times when a singleton really is he best choice, but in my experience it's usually the wrong solution.