A Rather Interesting Read
So, reading The Scientific Ninja, there is an article on why not to use singletons.
It's an interesting read about about why singletons are bad. Of course it goes overboard (Singletons are bad, will eat babies, etc, etc) but there are a couple of interesting points. I'm currently working with a codebase that is next to impossible to isolate into it's own module. For instance, one thing I wanted to do, as a test, was isolate the math codebase as it's own library. Doing this has proven to be a next to impossible task due to interdependencies that in my opinion shouldn't be there.
But in my opinion, there *are* a couple of systems in which a singleton *does* make sense. One that comes to mind immediately is a Resource manager.
A Resource Manager: To me, this is a prime candidate for the singleton pattern. Simply because, in a *game* there are enough subsystems that having global access to a well-referenced (and by well referenced I mean reference counted) system system for accessing assets, being able to hotload them and en does make sense.
I do have to say that the article has made me think a little harder about the use of a singleton. I have never liked the inability to definitely control it's lifetime (you can use some hacks to *mostly* clean up your singleton, but by definition there is always something left kicking around) but it's never stopped me from using it if I saw a system that would be of benefit from it. It does remind us that as programmers we still tend to go for the 'when all you have is a hammer, everything looks like a nail' idiom.
It's an interesting read about about why singletons are bad. Of course it goes overboard (Singletons are bad, will eat babies, etc, etc) but there are a couple of interesting points. I'm currently working with a codebase that is next to impossible to isolate into it's own module. For instance, one thing I wanted to do, as a test, was isolate the math codebase as it's own library. Doing this has proven to be a next to impossible task due to interdependencies that in my opinion shouldn't be there.
But in my opinion, there *are* a couple of systems in which a singleton *does* make sense. One that comes to mind immediately is a Resource manager.
A Resource Manager: To me, this is a prime candidate for the singleton pattern. Simply because, in a *game* there are enough subsystems that having global access to a well-referenced (and by well referenced I mean reference counted) system system for accessing assets, being able to hotload them and en does make sense.
I do have to say that the article has made me think a little harder about the use of a singleton. I have never liked the inability to definitely control it's lifetime (you can use some hacks to *mostly* clean up your singleton, but by definition there is always something left kicking around) but it's never stopped me from using it if I saw a system that would be of benefit from it. It does remind us that as programmers we still tend to go for the 'when all you have is a hammer, everything looks like a nail' idiom.
Powered by ScribeFire.
Comments