Categories:
/ (391)(rss)
   general (23)(rss)
      austin (4)(rss)
      random (5)(rss)
      scooter (4)(rss)
   tech (368)(rss)
      books (38)(rss)
      coding (10)(rss)
      java (160)(rss)
      jobs (8)(rss)
      mac (67)(rss)
      misc (55)(rss)
      net (16)(rss)
      ruby (4)(rss)
      xml (7)(rss)

JBoss:
A Developer's Notebook
JBoss: A Developer's Notebook

JBoss 4.0:
The Official Guide
JBoss 4.0 Guide

XDoclet in Action
cover

Recent Entries

Search entries

Referers Disabled(referer spam)

NetNewsWire blogroll

CapMac
blosxom

       

Fri, 05 Sep 2003

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

6 comments

writebacks...

Andreas Vallen wrote


Great article! I've just had to convert a web application from using lots of singletons to one that manages its own context. I dared the refactoring because I could rely on the ready-to-use xml-configured application context, that is part of the springframework. As you, its main architect makes a strong point against the use of singletons in his book "expert one-on-one J2EE design and development". The framework eases the burden of having to create and manage my own application context so much that I've weaned myself from the use of the singleton anti-pattern. see: www.springframework.org

Sheldon Hearn wrote


My response is available here: http://starjuice.net/2003_09_01_starjuice_archive.html#106300644888536345 I find the whole "Singletons are evil" as opposed to "Singletons are abused" point of view difficult to understand, so I'd really enjoy hearing feedback on this from others. I'm surprised nobody else has posted comments here yet.

cheesemelt wrote


A compelling case where a singleton is needed: an object that runs timed events? For instance, where all users need to see whether the timer is currently running or not - easiest to use a property named "runStatus" in a singleton class. It's important that no second timer be started if one is already running; this example came from an auto-emailer routine.

Vanity Foul wrote

On Loathing Singletons
Norman Richards posts on the ever-popular topic the evil that is singletons . I've never understood these discussions (that is, no one has ever presented what I see to be a compelling point), and here Norman grants a HUGE caveat: Most of the time,

J. Betancourt wrote


Many articles like this are very useful, however, they don't always offer concrete guidance or bullet points. At least, Rod Johnson tries in his book (though I found it vague on this issue, and seems not to offer a real way to get rid of them [but I could have missed it]). A similar topic to this is Exceptions and Error returns. Yeah, yeah, but what are the real issues and how to determine which and why, etc. If I wanted to argue about something and never come to any conclusions or practical resolutions I would be in politics or become a sports fan.

Johannes wrote

none
Well, imho these opinions 'Singletons are evil' are based by the real bad smell of misused patterns. Yes, the singleton pattern is a good pattern , IF AND ONLY IF you really need a singleton. I have, as yet, not seen many cases, where a singleton was really needed. Usually it is misused as global variable, as the architects and the programmers did not know about inversion of control. Singletons start to be a BIG pain when it comes to testing. You usually have great difficulties replacing the singleton with test classes. Okay, you don't test and you don't care about this. My statement is: Singletons are usually misused as global variables. Therefore singletons are usually evil. And it is a very tough business to convince "great" architects, that global variables are still bad, even if they use the singleton pattern.

comment...

 
Name:
URL/Email: [http://... or mailto:you@wherever] (optional)
Title: (optional)
Comments:
Save my Name and URL/Email for next time