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

Mark Hammond MarkH at ActiveState.com
Fri Oct 13 21:10:20 EDT 2000


> "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?

Just to be clear, that is not necessarily what I mean.  For this
specific COM example, a useful pattern can be:

# The real work class.
class FooBar:
  def DoSomething(self):
     # Do the real work...
  etc

class COMFooBar:
    _reg_progid_ = "..."
    _reg_clsid_ = "..."

    foo = FooBar() # The real doer instance, shared between all
instances of me.

    def DoSomething(self):
        return self.foo.DoSomething()

This allows you to instantiate as many COMFooBars as you like, and get
what is effectively "singleton" behaviour.  It also looks quite nice,
as the "COMFooBar" class can concern itself only with the COM
interface, while the "FooBar" class can concentrate on the work.
Obviously, if you have alot of methods, __getattr__ tricks could
probably perform automatic delegation...

Mark.






More information about the Python-list mailing list