From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2008-01-17 02:15:55
Pierre-Jules Tremblay wrote:
> On Jan 16, 2008 2:29 AM, Johan Nilsson <r.johan.nilsson_at_[hidden]>
>> Pierre-Jules Tremblay wrote:
>>> My biggest problem with this design is that it is unsuitable for
>>> library writers: types derived from typical singleton class designs,
>>> including boost::singleton and friends under review, invariably give
>>> rise to
>>> untestable code. To make a singleton's client code testable
>>> involves exposing some kind of overridable factory so that the
>>> singletonized type can be replaced with a test mockup. So far I
>>> have found this to be a hard problem to solve in general.
>> Did you notice that it is possible to use multiple inheritance? This
>> way you can implement and test your domain-specific logic as a
>> "normal" class, and then just expose a singleton of that specific
>> type using e.g. boost::singleton<>.
> Yes, it makes it possible to test the class to be wrapped as a
> singleton. That's the easy part. The hard part is to make the
> singleton's client code testable.
> If I have a singleton class A that wraps a "regular" class B, I can
> test B independently of A. However, I have no way to test any code
> that calls A::instance to get to B.
That's why you should use dependency injection instead of designing the
client code to directly call A::instance(). Why does the client code need to
know it is accessing a singleton, when all it wants is the domain-specific
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk