Re: Singleton

From: Hoff, Todd (todd_at_possibility.com)
Date: 10/29/03 

Date: 29 Oct 2003 20:30:07 GMT

"Roger L. Cauvin" <roger@deadspam.com> wrote:
> Services? Most flexible, maintainable systems are primarily the
> integration of various cohesive services. At a coarse level of
> granularity, virtually every package and facade represents a service. In
> fact, even at the individual class level, virtually every class is a set
> of behaviors that combine to represent a service. If your criterion for
> using singletons is whether the system requires "services", then you
> might as well make most classes singletons (combined with factories if
> you like).

How much of your code requires and indirection before you know
what kind of thing to use? Not a great deal i would imagine.
I don't usually go to a string factory or a list factory to
get strings and lists. You could imagine such an architecture though,
but it's not necessary most of the time.

If you have an abstract DOM interface, for example, and the implementation
will be decided at runtime, you know you need some global
access strategy. To me it's very clear to go to the DomFactory or singleton
and get the one that was chosen for your system. There's no
need for registries or other intercessors.

You have a bootstrap problem. How does my first object get the
DOM instance so it can pass it around? Do all my objects need
to come from a god object that can pass me the instance?
And if my god object can get the instance, why can't all my
other objects get in the same way? If the interface is clean
this is a one liner.

In short, there's no reason for all objects not to access interfaces
in the same way. It is the simplest and cleanest thing to do.

> > That's a lot of code IMHO, so i find the passing
> > around approach not as benign.
>
> Michael Feathers (and I) disagree with your assessment of the burden of
> passing arguments.

I am sure we disagree about many things. But i do have reasons
for my take as do you. That you don't find my reasons convincing
doesn't mean they aren't valid.

> He can correct me if I've mischaracterized his
> remarks, but Michael explained that a well-designed system doesn't
> typically require passing around a single object to a large number of
> other objects and methods in the system.

Could we possibly disagree on the definition of large and the
definition of well designed and where we make the ugh cutoff?

I find a large percentage of domain code needs access to these
services. That's a lot of code IMHO. If you have well factored
code it's even more because each little class would need access
to the services too. You could of course maintain the unbroken
chain of argument passing, but is that really the clearest
and simplest thing? It's a matter of judgement. I don't think
it is.

> > The commonly mentioned problems can all be
> > ameliorated by combining the notion of singleton
> > and factory together while separating singletoness
> > from a particular class.

> I don't think the factory approach addresses the problem with unit
> testing that Michael raised.

As mentioned in my posting you unit test a class separate from the
singleton or factory interface. So unit testing is not impacted.
Singletoness is a policy applied to a class, not part of the class itself.

> I accept that you have tried all of the approaches, but Michael and I
> (and a number of other folks, including Kent Beck and Ralph Johnson) have
> had different experiences and drawn different conclusions than you.

As we are separate people with separate experiences with different
tolerances and preferences, would you not expect this? I don't think
whacking me over the head with arguments from authority will really
accomplish anything. 

-- 
Do a caterpillar and butterfly speak the same language?