Singleton vs Proxies DP (was Re: Solution: Direct access to Printer I/O lines)

[Dinu C. Gherman]

Alex Martelli wrote:
> 
> "Carel Fellinger" <cfelling at iae.nl> wrote:
> >
> > And in an other thread you wet my appetite and direct me here!
> > So let us hear that rant, mister, and enlight us mere mortals
> > who still think that there is legitimate use of this singleton
> > pattern.
> 
> [...]
> 
> Within the component that implements the singleton, it
> does not matter how and where you place the state, and
> the code that knows about that state's representation and
> accesses and modifies it directly.  You may choose to
> have that state as instance-variables of an object, that
> code in its methods, and ensure a single instantiation of
> that object, but that's a somewhat roundabout way for
> languages which allow per-class (C++) or per-module
> (Python) functions and data.  But it's a minor decision, of
> implementation more than of design; what matters is the
> interface you choose to expose from that component.
> 
> And _should_ that interface be one of a single object that
> gets instantiated once, so it must be accessed through
> some single 'give me a reference to Mr. Singleton please'
> function?  I do not see why that could ever be the ideal
> interface.  There are all sorts of issues that give slight
> problems, and I don't see any compensating benefit when
> compared with the following approach.
> 
> Why not have client-code ask for objects normally,
> use them, then drop them when it's done?  If client
> code asks for 'another object' -- why not hand it out?
> 
> It doesn't matter if the 'handed out' objects have
> different *identities*... as long as they share *state
> and behavior*, no?  I forget on what name this simple
> pattern was originally published in "C++ Report",
> but let me call it 'lightweight proxies' (LWP, versus S
> for the singleton pattern).  It's just one of many, many
> examples of the benefits that can often be had by
> splitting notions of id and state in OO programming.
> 
> [...]

The GOF book defines a Singleton rather clearly as a
*unique instance* of a class (while it does not exclude
that a limited number > 1 of instances might also be
useful, sometimes). IMHO, a unique identity is part of
the pattern as you will often have the case where the
*usage* of a Singleton, i.e. the time windows in which
it is used by multiple clients do overlap. In fact, I
think this is the regular case for this pattern, while
you seem to argue in favour of use-cases where clients
immediately drop their handle to that one or *same*
instance and there is no overlap.

Of course, you're free to implement the pattern in what-
ever way you like, but if, as you seem to do, define your
Singleton pattern as multiple instances sharing behaviour
*and* state, i.e. while allowing for different identities
as well (in the general case) I'm tempted to suggest, may-
be, a different name, like Clone, Replicant or something
similar. A Proxy, at least to me, always means a place-
holder for some *other* object, like "intelligent poin-
ters" or the like. Well, if you add a Decorator to your
pool of Clones you might get a Singleton again, but then,
why would I do that? Doesn't a large pool of Clones mean
a waste of memory?

Anyway, it probably all depends on the the problem you
want to solve and the forces being at work, as well as 
your personal preferences... 

Glad-to-see-more-pattern-threads-again'ly,

Dinu

-- 
Dinu C. Gherman
................................................................
"The only possible values [for quality] are 'excellent' and 'in-
sanely excellent', depending on whether lives are at stake or 
not. Otherwise you don't enjoy your work, you don't work well, 
and the project goes down the drain." 
                    (Kent Beck, "Extreme Programming Explained")