no singletons, please (was Re: an example Re: Connecting to running win32com server)

[Alex Martelli]

"Glyph Lefkowitz" <glyph at no.spam> wrote in message
news:m38zrtsuqq.fsf at DHCP-98-129.origin.ea.com...
> "Alex Martelli" <aleaxit at yahoo.com> writes:
>
> > it's often best to *decouple identity and state*, by having
> > many objects (different identities) *sharing state*, rather
> > than trying to ensure the state-sharing happens through all
> > object being one (having the same identity).
>
> I'm not quite clear on what you mean by that.  Do you mean something like
>
> class FooBar:
>   MyState = {}
>
>   def __init__(self):
>     self.__dict__ = MyState
>
> What good would that do?

For example, it lets client code use:
    x=FooBar()
to 'generate' variables of class FooBar, for example -- decoupling
client-code from the decision (that rightfully belongs to the
designer of FooBar -- maybe the same person, but wearing
different hats:-) to share-state.


> > This applies to COM (in any language), but also outside of it.
> >
> > "Same-Identity" can be a heavy burden to carry around when
> > all one really wants to ensure is "Same-State"... which is
> > most of the time when one starts thinking "Singleton"!
>
> And besides, "singleton" is just the 90's way of saying "Global
> Variable", since Global Variables are bad style for a variety of
> reasons, but "Singleton" is a design pattern, and therefore must be
> good... sheesh
>
> When I have something that looks like a "singleton", I almost always
> store it as a bunch of global state in the module that it's related to
> rather than devoting a proper instance to it.

Fine, but letting client code access it through class instances
is often a good idea anyway.  In COM, for example, it's
absolutely mandatory, since you _must_ give out to clients
what amount in Python terms to class instances.  In the
Singleton Pattern, one would strive to give out the same
instance to each client (leading to problems of various kinds);
in the "instances sharing state" pattern (which needs a flashier
name:-), one blissfully gives out instances at will, and just
has each of them delegate its state.


Alex