A friend of mine gave me his old N95 8GB just a couple of days ago and I was kinda let down to find out that the volume rocker didn’t work, since one of the things I was looking forward to the most was filling up the storage with music to listen during my commute.

This did the trick, though! It took a few tries, but It’s working perfectly, now! It’s pretty awesome to see how many people you’ve managed to help with this little fix!

Just to clear up the terminology a bit, you mention you use enums to “store a bit of state”. By which I assume you mean that they have attributes. It’s important to note that a singleton that has a “state” in the sense that that state could change, would suck. No, let’s make it clear, a singleton that is mutable would be pure evil. If Elvis had methods called “startDancing()” and “stopDancing()” or even any references to mutable objects then you can expect trouble ahead. A singleton that has references to a database is obviously a bad design.

Here’s a post from the Google testing blog that largely agrees with your point but does briefly mention that the real trouble with singletons comes when you allow mutability.

Elvis is allowed to have behaviour, methods that do stuff, just not methods that change Elvis’ state. For example, this would be ok:

1
2

Elvis theKing = Elvis.INSTANCE;
SimilarityScore briansScore = theKing.rateImpersonator(brian);

Elvis theKing = Elvis.INSTANCE;
SimilarityScore briansScore = theKing.rateImpersonator(brian);

A common argument against the use of singletons is that you do not declare your dependence on the singleton in your API. If an object requires an Elvis then the argument is that it should be declared in the constructor. Clients of your object then know that you need an Elvis to work. My argument is that sometimes, the use of the singleton in none of the API’s beeswax, it’s an implementation detail. You wouldn’t expect an object to be constructed with pi.

I think the singleton is a good way to represent something that exists only once in the universe, and never changes. Like Elvis.

There’s even a delicious irony in that, over the two articles, you’ve tried to press gang an enum into service as a singleton, only to end up with a singleton that looks really rather like an enum! Your Elvis object is an excellent representation of the real thing: like the real Elvis it has some attributes that will never change and like the real Elvis it doesn’t do a lot because the real Elvis is, well, dead. I regularly write enums that do much the same (that is to say, they just store a bit of state, not that they die). If this is a singleton then I don’t have any problem with it.

I do have a problems with what you might call behavioural singletons, however. Once you’ve hooked up with a singleton that does things, you’ll be doing things his way forever after. Want to unit-test the code that depends on that database singleton? Well you’d better have a database handy then. Want to run those tests as part of an overnight build? Brace yourself for a lot of spurious test failures every time the database has a bilious attack. Want your code to get its data from somewhere other than that miserable, stinking database? Ha – forget it!

As you say, the moment you try to unit test a piece of code like this, you’ll most likely realise that the singleton’s giving you gyp and remove it. But this only leaves me wondering why you’d use the bloody thing in the first place. Have we hit the limits of singletons with Elvis, or do you think there’s life in the old goat yet?