Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?

Subject: Re: [boost] Is there interest in an alternative to the Singleton anti-pattern?
From: Matt Chambers (matt.chambers42_at_[hidden])
Date: 2011-06-23 02:58:25

On 6/23/2011 1:08 AM, Ben Robinson wrote:
> The Singleton pattern does have its uses because it guarantees a single
> instance of a class.  However, it suffers from three weaknesses:
>
> 1) Encapsulation: Singleton provides global access to the class.  Some may
> view this as a feature, but advocates of unit testing, and dependency
> injection would disagree.
> 2) Initialization: Singleton restricts the class to the default constructor.
>   This makes Singleton unusable for classes which require non-default
> constructors.
> 3) Lifetime: Singleton introduces lifetime management complexities (for a
> detailed discussion, see Chapter 6 of Modern C++ Design by Andrei *
> Alexandrescu*).
>
> I have formalized what I believe is a novel design pattern, which guarantees
> a single instance of a class, but which does not suffer 1-3 above.  And
> unlike Monostate, this pattern I propose does instantiate a genuine instance
> of any class, using any one of its available constructors.  I hope this
> inquiry peaks your interest.

I've often wondered about singleton's bad rap (other than the difficulty of 
making them reliable in C++). I use a singleton from the boost vault for hiding 
implementation details of globally accessible interfaces (e.g. an interface to 
access information about elements of the periodic table when I don't hard-code 
all the constants). This usage is unit testable as long as the implementation 
details can be thoroughly tested through the interface. It could support DI too 
if the dependencies are given to the singleton's methods instead of at construction.

I don't understand weakness #2. My usage of singletons makes initialization an 
implementation detail. Construction is not part of the singleton's interface 
because constructing it different ways from different parts of the program would 
mean having more than a single instance.

#3 is a indeed a bitch with C++. The boost vault solution I use makes it quite 
easy to chain singletons though.

Nevertheless, my interest is piqued.

Thanks,
-Matt