The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Former Singletonholic, now statically sober

A while back there was a thread on Singletons.  Someone posted a rather humorous article about Singletons.  I can't find the post (searching "Singleton" has a ton of results, and I can't figure out the order of the display).

Anyway, after carefully reading the comments in the thread on singletons and the linked article, I have recognized the error of my coding ways.  Every time I've used a Singleton, a static class would have sufficed.  I am guilty of singleton bloat.

I'm a convert.  I feel like a reformed sinner. I understand there are some rare cases where a singleton is required, but I'm not seeing the need any time soon... it is too specific.
OneMist8k
Monday, October 01, 2007
 
 
Huh?
There goes me thinking that one is more or less equivalent to the other.
I didn't read any such discussion but both are symptoms of bad design.

I say, use neither, unless there is a valid reason why there should only be one instance of the object.
Unfortunately it comes down to thinking about your design rather than just following instructions.
Jax
Monday, October 01, 2007
 
 
Singletons are used to ensure only one instance of an object is created.  Seems simple, right?  But the more I read about  it, the more potential problems I found.  Hidden problems.  nasty problems.

Someone posted a link to a very well written and humorous piece authored a few years ago in which it was explained that in most cases, static classes do just fine, thank you very much.

* click *  The lightbulb above my head turned on.

I saw the light. 

If I ever find the person that posted it, I'll send over a Starbucks venti whatever.  I'm grateful for my enlightenment.
OneMist8k
Monday, October 01, 2007
 
 
If the classes have data, aren't they just another form of giant evil global variables?

Seems like it's best to avoid them both, if possible.
JW
Monday, October 01, 2007
 
 
"giant evil global variables" ???

Globals aren't evil if used correctly. The non-evil globals are know as aspects.
Dino Send private email
Monday, October 01, 2007
 
 
In my experience (in C++ anyway) a singleton is better because you don't know the order in which the compiler will initialize the static classes so you might get in trouble if you have static classes that reference other uninitialized static classes. Singletons insure that the classes have been initialized when they are referenced.
Kevin
Monday, October 01, 2007
 
 
Well there are definitely places where a static class does just fine and a singleton pattern is overkill. But singletons obviously have their place as well. There are many benefits to using a singleton over a static class that I won't go into here since you apparently have read other articles about it.

Suffice it to say that this is just one more instance of the case where you really need to apply the correct pattern based on the situation at hand. Nothing new or novel about that idea.

But its also good to know that you are doing your part to rid the world of singleton bloat! :)
anon
Monday, October 01, 2007
 
 
All my reading was on singletons in Java, use of singletons in multi-threaded applications, and behaviors with multi-core processors because of an earlier flaw in the Java memory model.  I don't know how many of these problems (and others) are present in other languages.
OneMist8k
Monday, October 01, 2007
 
 
Two advantages that singletons have over static globals:

For static globals, you don't know what the order of initialization will be -- the compiler chooses.  For singletons you know because you can specify.

Also, static globals get initialized before the debug symbols get loaded for a shared object under Linux, which makes it a painful to debug.
Joe Turner Send private email
Monday, October 01, 2007
 
 
sgf
Monday, October 01, 2007
 
 
Consider that, in a static class, the item being managed is initialized *whether or not it is being used*. In a singleton, it is initialized *the first time it is used*. This may have a great bearing on which is appropriate depending upon the requirements of your design.
Just A Guy Send private email
Monday, October 01, 2007
 
 
Now I'm dying to read this article. Anyone?
andy
Monday, October 01, 2007
 
 
There was both a flaw in the Java memory model and a flaw in the developers who didn't understand concurrency. Only one has been fixed.

When a static class would surfice instead of a singleton, then you probably don't need a static class either. Saying that one is the better than the other in this case is wrong - both are plain bad. Static classes are usually only used for utilities/factories - not out of need, but because developers find it more beautiful to do Utils.operation() rather than new Utils().operate().

A singleton provides dynamic dispatching and is therefore more appropriate than a static clas /when you need a single instance/. Caches are perfect examples, since you may want to operate against the generically (e.g. refresh()) and only need one instance.

I try to avoid static variables / classes in general since it is usually cheap to construct them and a waste of memory to leave globals around forever. You use them only when appropriate.
Benjamin Manes Send private email
Tuesday, October 02, 2007
 
 
I guess you refer to the Double-checked Locking with Singleton pattern:

http://www.ibm.com/developerworks/java/library/j-dcl.html

In that case, the problem isn't the Singleton pattern itself but the poor use of synchronization.

Singleton is seemingly a simple pattern but it's correct use can be tricky, but I think it has its uses when you know what you are doing. Saying that Singletons are bad but static classes are good is somewhat simplistic IMO
Christophe Keller Send private email
Tuesday, October 02, 2007
 
 
Slightly OT, but Kevlin Henney did a very entertaining talk titled "Pattern Connections" at the ACCU Conference (http://www.accu.org) this year which touched on this subject.

The quote "Forgive Me Father, for I Have Singleton'ed" now inevitably springs to mind every time somebody mentions the "S" word in front of me...
Anna-Jayne Metcalfe Send private email
Tuesday, October 02, 2007
 
 
The link to the original article is here http://steve.yegge.googlepages.com/singleton-considered-stupid

I made a post to say at the time the article was a dumb one, and it is. In summary it says "Singletons are only useful if you are sure you want only one of something - and sometimes you don't want only one". Well, duh! If the pattern isn't applicable, don't use the pattern.

Singletons have their place, and so do static (i.e. global) variables. Like most things in computing, it depends on the context.

Firstly, Singletons are only useful if you are sure you only want one. You have to be sure, but there are plenty of cases like that. An ATM only has one keypad interface; a cellphone has only one send button.

Singletons are better than statics when the cost of initialization is non-trivial. If you never interact with the Singleton then you never initialize it.

Singletons CAN be used if the Singleton can come in different types. Obviously the restriction still applies that "there can only be one", so the choice of type must be applicable to the entire lifetime of the app; the information to decide which type to instantiate must also be available at construction time, and that's hard to do. I've never done it.

I would, however, agree that Singleton tends to be overused. But the cure for immoderate use is moderate use, not total abstension.
DJ Clayworth
Tuesday, October 02, 2007
 
 
The article is hardly dumb (of course, I might be biased because I'm pretty sure I'm the one that posted the link).  He makes a number of strong statements, to be sure, but I think the entire point of the article is to make people think double extra hard about using Singleton, much like Djikstra's  article on goto.  Both are concepts that CAN be the right approach, but PROBABLY are not.  By giving the development community a sharp poke in the metaphorical ribs over it, hopefully people will take just a second before traipsing down well-trodden paths and hopefully overall code ends up better and everyone ends up happier.

Many of his articles are like this, making very strong statements that border on being indefensible.  He may well ultimately be wrong.  However, I believe they're still valuable because they make the readership think.  (Unless I've missed the news the world has never suffered from a surplus of thinkers, heh.)  I feel much the same about Joel; I frequently disagree with him but I come back to read anyway because at worst his writing usually makes me examine or think about some aspect of what I do every day.
son of anon
Tuesday, October 02, 2007
 
 
BillAtHRST Send private email
Tuesday, October 02, 2007
 
 
Even when you're sure you only want one of something, it's nearly always best just to make one, rather than make a singleton.

The problem with Singleton is that it encourages you to write your code such that there can only EVER be one. If that ever changes so that you need to make several, the Singleton code will really be in the way.

The Singleton pattern also has the property of making the one instance accessable from everywhere - which is both a convenience and a curse, like all global choices. The main reason for making Singletons is actually the convenience, in my experience. And sometimes it's worth it - but not all that often.

The reverse problem - that you accidentally make two when you only actually wanted one - doesn't tend to happen all that often. Normally if you only make one, you'll make it in one sensible place, and you'll always know in a function whether you've got a reference to it or not. And, of course, if you don't write the singleton it's absolutely trivial to make several if ever you need to.
Duncan Sharpe
Tuesday, October 02, 2007
 
 
There wasn't a problem with the memory model per se, but a problem with the way it was described in the JVM spec.

And theres a really simple way to fix it: initializing fields statically so it happens when the class is loaded. No threading problems. 

If I have a complex class hierarchy why would I make a bunch of fields static when I could just wrap it in a singleton?

The more I hear about Steve Yegge the more I'm realizing he's almost as clueless as Paul Graham.
SmartYoungAnonPoster Send private email
Tuesday, October 02, 2007
 
 
Singleton is a way to achieve a specific objective - namely, having only one global instance of a class.

A "static class" is one particular implementation of that concept.

The OP is much like someone going to an AA meeting and saying "I don't drink alchohol any more! no more beer for me! only wine!" and apparantly too drunk/excited to understand why that's a stupid statement.  ;)

Friday, October 05, 2007
 
 
What if your single instance object need to implement an interface because you use IoC/DI mechanisms and want to verify a spec/design using a test double? Would not a Singleton be better in this case?
dobedobe
Tuesday, October 09, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz