Re: Design Patterns
On 2/6/2013 11:40 AM, Daniel Pitts wrote:
On 2/5/13 5:34 PM, Arne Vajh?j wrote:
On 2/4/2013 11:10 PM, Stefan Ram wrote:
Arne Vajh?j <arne@vajhoej.dk> writes:
Pattern or anti-pattern, I never encountered a situation where I
felt a
need for ?singletons?.
Other have.
Maybe someone can come up with an SCSE where a singleton is needed.
Needed as in "problem can not be solved without"? I doubt such exist!
Needed as in "a large of programmers prefer it to solve the problem"?
There are many. Connection pools, configuration settings, web app
statistics etc..
Logging is another one. They thing about all those is that there is a
globally accessible shared instance, but that doesn't have to be
enforced by the class itself. Rather, the life-cycle of the object is
managed externally.
Self-managed life-cycles should be very rare. For instance, something
which actually manages external resources may need to enforce some
invariants about its life-cycle, in order to manage external state in a
sane manor. This isn't something an application programmer need worry
about on a frequent basis.
It does not need to enforce it by itself. But I do not see a real
problem of it doing it.
If one is already using a framework that can provide the functionality
then fine. But I would not add a framework to avoid writing the
singleton boilerplate.
I'm *not* a fan of a global Configuration object for many reasons. One
is that the configuration class becomes overly involved with the rest of
the application. At least, if they treat it as a place to "go grab some
settings". If the settings are injected, then that's a different story.
Up to a certain level I would prefer a single configuration
over multiple configurations.
Arne