I agree with you. His proposed solution is unnecessarily complex. I get really tired of seeing all these proposed design patterns that result in 5 classes when one do, with the justification that you may have to change something, and this magical way allows you to avoid the cost of change. I say it's BS. Usually you use singletons not necessarily because you want ONLY ONE, but because you don't want to create one everytime you need it. I think the pattern is fine if used when appropriate (duh).
I'm not saying to put performance and memory usage aside. If you want only one instance, only use one instance. That's perfectly valid. But that is a usage consideration, not a class design consideration. Simply provide a cached instance and use it. Problem solved. There's no need to PREVENT multiple copies from existing in that case.
Dave commented above "you use singletons not becessarily because you want ONLY ONE". That's EXACTLY my point. Singleton imposes one. You just want a cached copy. Why use the singleton then? It's not what you want. On one hand Dave argues against applying design patterns for no reason (or or you just arguing against design patterns involving extra classes?) and then goes on to promote an unnecessary use of singletons even though the pattern only gives you something you want as a side effect of what it's real purpose is.
Sorry for not commenting until now. I must have missed this post. (on the bright side, I have trackbacks now. And they might even work)
What I'm saying is that simplicity is key. A lot of times people use singletons to basically create global methods. In that case, a static method on a class is way easier than setting up some complicated caching mechanism. And, setting up a complex system of caching because you MIGHT need more than one instance of the data/methods you are initially putting in a singleton is pointless. You don't know that you will need that. You cannot (and should not) design a system that will handle everything you may or may not need. Oftentimes, a singleton is the simplest way to solve a problem. You simplly need to share some data or code globally and don't want to be creating new objects all the time.
So, I am arguing for simplicity. I see singletons as a coding pattern, I guess. Something to make your life easier while accomplishing our goals. If I was managing a team and an engineer went off and designed and built some caching system of abstractions instead of just uisng a Singleton, you better believe I would be pissed if they didn't have a DAMN good reason.
Not to turn this into a discussion forum, but perhaps you simply want the static getInstance() without the private constructor? You get the global variable you want without impossing the overhead of a singleton.
That's not a singleton though. That's a (somewhat inelegant) cached instance. Why then go the extra mile and impose the complexity and inflexibility of a true singleton?
In your comment you say "Simply provide a cached instance and use it". Couldn't the Singleton pattern be considered a much-simplified cache? A cache of one? What I see you arguing against is the restriction on the Class's constructor (making it private) - is that right? But don't most Factory patterns likewise make use of hiding/shielding the constructors?
The following applies to Java, since that is what I know - it could apply to other OO languages.
I can imagine a Singleton implementation that uses the constructor itself, rather than the getInstance() method, except that constructors have additional costs (covered elsewhere in "Constructors considered harmful" or somesuch).
Posted by
Lance
on September 18, 2003 at 03:25 PM CDT
#
Note that I don't practice what I preach ;-)
In Roller I created a RollerFactory, for getting and returning a single instance of the Roller persistence layer. This is, in effect, a singleton (notice the lower-case 's'), but using a Factory.
But I actually had another reason: RollerFactory is responsible for returning the *configured* version of the persistence layer. This is how Roller supports using either Castor or Hibernate. If it weren't for that, it would have likely been a Singleton. Before I wrote the Factory it was (unnecessarily) returning a new instance for every request, which would most easily be solved by a Singleton.
Posted by
Lance
on September 18, 2003 at 03:37 PM CDT
#
Yes, my complaint is the hidden constructor. That's critical for a singleton - FORCING a single instance. Without that, you only have a cached instance. (sorry, I don't have a better name) I'm not arguing against that. That may or may not be a good thing, but it's necessarily a different thing than a singleton.
When most people say "singleton" they really just mean "cached copy / global variable". The problem, is that they apply the real singleton pattern, which is to force the single instance, simply because it's part of the pattern.
Even if you can live with a singleton in your deployed instance, I don't see how anyone can thoroughly unit test around a singleton, unless it has no configured state. And even then I have a hard time buying it.
Posted by Dave on September 09, 2003 at 02:41 PM CDT
Website: http://www.naildrivin5.com/davec #
Dave commented above "you use singletons not becessarily because you want ONLY ONE". That's EXACTLY my point. Singleton imposes one. You just want a cached copy. Why use the singleton then? It's not what you want. On one hand Dave argues against applying design patterns for no reason (or or you just arguing against design patterns involving extra classes?) and then goes on to promote an unnecessary use of singletons even though the pattern only gives you something you want as a side effect of what it's real purpose is.
Sorry for not commenting until now. I must have missed this post. (on the bright side, I have trackbacks now. And they might even work)
Posted by norman richards on September 18, 2003 at 02:55 PM CDT
Website: http://www.jump.net/~orb/ #
So, I am arguing for simplicity. I see singletons as a coding pattern, I guess. Something to make your life easier while accomplishing our goals. If I was managing a team and an engineer went off and designed and built some caching system of abstractions instead of just uisng a Singleton, you better believe I would be pissed if they didn't have a DAMN good reason.
Posted by Dave on September 18, 2003 at 03:08 PM CDT
Website: http://www.naildrivin5.com/davec #
That's not a singleton though. That's a (somewhat inelegant) cached instance. Why then go the extra mile and impose the complexity and inflexibility of a true singleton?
Posted by norman richards on September 18, 2003 at 03:18 PM CDT
Website: http://www.jump.net/~orb/ #
In your comment you say "Simply provide a cached instance and use it". Couldn't the Singleton pattern be considered a much-simplified cache? A cache of one? What I see you arguing against is the restriction on the Class's constructor (making it private) - is that right? But don't most Factory patterns likewise make use of hiding/shielding the constructors?
The following applies to Java, since that is what I know - it could apply to other OO languages.
I can imagine a Singleton implementation that uses the constructor itself, rather than the getInstance() method, except that constructors have additional costs (covered elsewhere in "Constructors considered harmful" or somesuch).
Posted by Lance on September 18, 2003 at 03:25 PM CDT #
In Roller I created a RollerFactory, for getting and returning a single instance of the Roller persistence layer. This is, in effect, a singleton (notice the lower-case 's'), but using a Factory.
But I actually had another reason: RollerFactory is responsible for returning the *configured* version of the persistence layer. This is how Roller supports using either Castor or Hibernate. If it weren't for that, it would have likely been a Singleton. Before I wrote the Factory it was (unnecessarily) returning a new instance for every request, which would most easily be solved by a Singleton.
Posted by Lance on September 18, 2003 at 03:37 PM CDT #
When most people say "singleton" they really just mean "cached copy / global variable". The problem, is that they apply the real singleton pattern, which is to force the single instance, simply because it's part of the pattern.
Even if you can live with a singleton in your deployed instance, I don't see how anyone can thoroughly unit test around a singleton, unless it has no configured state. And even then I have a hard time buying it.
Posted by norman richards on September 19, 2003 at 02:46 PM CDT
Website: http://www.jump.net/~orb/ #