Why should i use python if i can use java

Alex Martelli aleaxit at yahoo.com
Thu Jun 7 15:56:36 EDT 2001


"Don Dwiggins" <dwig at advancedmp.net> writes:
    ...
> Alex Martelli quotes Glyph Lefkowitz:
> >> > an elegant way of implementing singletons (or does it? anyone?)
> >>
> >> Aah, the singleton.  Global variables for the new millennium.  First of
> >> all, the singleton "pattern" is usually a bad idea.  If you have a
class
>
> > *AMEN, HALLELUJAH*!  This makes two of us sharing this dislike
> > for the Singleton Design Pattern, so I'm not a Singleton any
> > more -- see, that's one typical issue with Singleton DP, what
> > starts out as a singleton often becomes not one:-).
>
> According to the GOF "Applicability" section on Singleton:
>    Use the Singleton pattern when
>    - there must be exactly one instance of a class, and it must be
>      accessible to clients from a well-known access point.
>    - when the sole instance should be extensible by subclassing, and
>      clients should be able to use an extended instance without modifying
>      their code.
>
> If you take the whole description of the Singleton pattern seriously, to
say
> that you "hate" the pattern would seem to mean that you don't believe that
> programs should ever need something that satisfies these criteria.  Is
that

First of all, I said not 'hate' but 'dislike', and Glyph said "it's usually
a bad idea".  But the crucial thing is: I opine the SDP does *NOT*
tend to optimally resolve the forces thus identified!

> true for both of you?  Whether it is or not, I'd like to hear a bit more
> explanation for the strong emotional reaction to the pattern.

I've posted very extensively about it, and how I prefer 'lightweight
proxies' instead -- instances that have no state (but rather delegate
all state, and possibly all behavior, to a singly-instanced object not
exposed directly to client code) but are freely instantiable at need -- and
specifically what different advantages this brings in different contexts,
such as Python, COM, and so on.  Of all the issues, the key one is that
LWP is more change-proof than SDP in my experience -- "there must
be only one" is, out of all design constraints, one of those that most
tend to change in an iteration.  Refactoring LWP's is trivial, refactoring
SDP typically isn't.

But take the subclassing.  Why should different client parts need the
same subclassing?  They may want to use different mixins, decorators,
and so on.  How do they do that on SDP?  They don't.  How do they
do that on LWP?  Trivial.  Of course, the in-one-single-instance obj
(not exposed to normal client code) may be subclassed at will (and
variously played with in Python) if something is needed that all
clients will 'see' at once -- as LWP's delegate state & behavior.


Alex



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com





More information about the Python-list mailing list