On Tue, Jun 30, 2009 at 12:37 PM, Paul M Foster<pa...@quillandmouse.com> wrote:
> On Tue, Jun 30, 2009 at 11:17:17AM -0400, Eddie Drapkin wrote:
> <snip>
>> I wouldn't really recommend going with a singleton in this situation,
>> as there exists a different solution (my other post :P) and there are
>> very few actual use-cases where the pattern makes sense, and deploying
>> it unnecessarily can cause a whole lot of headache D:
> I disagree. A singleton is quite a good solution, particularly when you
> only want one instance of an object. You can also create a "registry"
> class which contains instances of objects which might be useful to other
> classes.
> Why would a singleton lead to headaches?
> Paul
> --
> Paul M. Foster
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

If you only want one instance of a class at any point, that's the
whole purpose of the pattern, so how could I argue against that?  All
I said was it's really rare that there's a justifiable reason (and in
the above example, it's simply to compensate for not wanting to handle
it elsewhere i.e. laziness) to actually use the pattern.  A lot of the
times you see singletons in use, it's for ease of use, not
functionality; database layers, for example, have no necessity of
being singletons and it's restrictive to do so, yet it's done all the
time.  For a generic question like this, suggesting a single design
pattern as the solution is a bad idea, as someone who doesn't know
better will assume it's the only solution, thus leading to those
headaches of dealing with a misapplied paradigm to a particular

As far as the registry class paradigm goes, it's occasionally useful,
as is the singleton pattern, but it's not a solution I'd necessarily
recommend because of the overhead implications, especially not in such
a simple situation as storing an instance in a static variable.

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to