From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2008-01-17 08:52:56
Tobias Schwinger <tschwinger <at> isonews2.com> writes:
> Anthony Williams wrote:
> The responsibilities of a Singleton. Citing another post (sorry for the
> redundancy -- I think I'll add a brushed-up version of this list to the
> 1. Making the user implement a class
> 1.1. encourages a well-defined object interface,
Only if people can manage to use one singleton per role.
> 1.2. embraces a design that can easily be changed to use non-globally
> scoped objects instead, and
I disagree there. Uses of singletons cannot easily be changed to use
non-globally scoped objects.
> 1.3. prevents pollution of the global namespace.
Not really: you have to provide a class name rather than a variable name.
> 2. Providing on-demand initialization
> 2.1. makes non-trivial construction work with any ABI's shared libs, and
> 2.2. automatically resolves dependencies between Singletons.
As I mentioned before, this is orthogonal to Singleton: the responsibility of
singleton is to ensure there is one and only one instance, not to provide
on-demand initialization. This is also easily provided by other means.
> 3. Ensuring a single instance of the Singleton class
> 3.1. allows to properly model unique facilities (hardware, registries,
> etc.) in an object oriented fashion, and
This is the crux of the matter. Just because there is only one printer, doesn't
mean that you have to enforce a single instance of the Printer class. Just
create one instance, and pass it down with dependency injection.
> 3.2. allows to encapsulate a well-defined access point in the first
It might be well-defined, but I'd argue that it's not well-designed.
> >>> I've written code that used singletons (and regretted it later), and used
> >>> code that other people have written containing singletons.
> >> So you should like this library: The design chosen allows you to easily
> >> substitute Singletons with Smart Pointers.
> > I disagree. If people know something is a singleton, then they don't bother
> > keep the reference around, as they can get it again later. Changing code
> > that
> > does that to code that can use a passed in instance requires adding
> > parameters
> > and/or storing references. You can't just change uses of a singleton to use a
> > smart pointer instead without thought to *how* it's being used.
> I won't argue on this one. I can imagine that having to refactor a mess
> like this is a most unpleasant experience.
> Still it's not the fault of the Singletons but of developer's laziness:
> At least the developers in the project you mention had a choice whether
> to write flexible code or not. With globals and static functions, they
> wouldn't have had a choice but to make a mess.
Singletons *are* globals.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk