voodoo: modifying class methods a posteriori

Hung Jung Lu hungjunglu at yahoo.com
Wed Sep 19 08:49:24 EDT 2001


slinkp23 at yahoo.com (Paul Winkler) wrote in message news:<slrn9qgcg8.13u.slinkp23 at roaddog.armsnet>...
> This is exactly what the Decorator design pattern is for.  

I don't think so. :)

(1) In real-life programming, what I have explained is a real need. In
an actual commercial software development, you typically have many
people collaborating, and you use third-party modules. Everything is
moving at the same time, and some modules are not under your control.
So, very often, it's best practice not to touch other people's codes.
Now, the other people have a whole package of many modules and classes
and subclasses, and you want to modify the behavior of a superclass,
at some branch of the complicated class hierarchy structure. What you
have described is nothing but a more elaborate way of class
derivation, and it does not help, because you'll have to copy and
re-do the whole class hierarchy tree, when all what you wanted was to
modify one single method in the superclass. In other words, you cannot
modify the behavior of existing objects in your approach: you are only
introducing new classes, new objects. In C++ and in Java, you simply
cannot modify the behavior of a superclass's methods, no way Jose,
that's part of the corporate security concerns inherent to those
languages. In Python, you can. You can insert hooks almost at will.

(2) Beware of the word "pattern". It's fad, I know. But "pattern
programming" is nothing but a rephrasing of "give me an example,
please". I've seen fads come and gone, and "pattern" seems to be one
of them. :)

regards,

Hung Jung



More information about the Python-list mailing list