I’m currently “updating” my development knowledge especially on TDD principles by reading books, articles on the web and watching videos. Something that pops up everywhere is the warning, not to use global state variables as they make the system fragile and less easy to test and since singletons are not much better or rather the same, not to use those either.
Now I’m wondering: Can I actually be consistent about this?
- What about a cache, that the application uses so it doesn’t have to look up frequently used database objects again and again? I NEED a single instance of that cache to be passed around, otherwise what would be the point?
- Another example are DAOs or as we call them providers. They do nothing but provide JPA database access for us but otherwise have no state. So why not make them singleton?
- And controllers in the web frontend? All they do is react to requests – again with no internal state.
Wouldn’t it waste a lot of performance instantiating the latter two again and again? I’m sure there are a few more examples where this applies.
Maybe it’s okay to use singletons, as long as they don’t have any member variables except for finals?
And even if they have member variables but all of them are injected into them, it should be save to use them, as any object, singleton or not, can modify injected objects so it really doesn’t make any difference.
I’m a bit confused about this whole “avoid singletons” business, I’m not even sure I fully understand the risks involved. But most of all I’d like to hear thoughts on the above examples, as those are the most common places in our application where we use singletons.
Thanks!
btw: we’re using springs dependency injection, so how to do it is not my question, rather why avoid it and where it is okay.
The issue with Singletons is not so much the Singleton design pattern per se as their being overused under the covers as stateful global God objects all over applications.
That way of using them has 2 major drawbacks :
Dependencies on singletons are hidden dependencies, and objects are tightly coupled to them, which hampers discoverability, maintainability and testability of the code.
Objects depend on singletons they don’t have any idea which state they’re in. The order in which a singleton’s behaviors are used here and there starts to become important, and you start seeing “MySingleton.Initialize()”s all over the place, which is dangerous and defeats the whole purpose of having a single instance.
Only singletons that trump these pitfalls are IMO worth considering – that means stateless, immutable objects that somehow get injected into their consumers and can be replaced with other instances with the same contract.
Other than that, Singleton-ification is most often premature optimization applied on the wrong objects.
This blog post pretty much sums it up : http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx