a new design pattern for Python Library?

Ben Sizer kylotan at gmail.com
Thu Nov 24 05:13:29 EST 2005


The Eternal Squire wrote:
> Suppose I have a central class with complex behavior that I want to
> simply write as a bare skeleton upon which to hang the auxillary
> classes that help provide the complex behavior.

So, it's akin to the GoF's Template Method or Strategy patterns, then.

> What I will typically do is create the auxillary class as a friend so
> that I can have tighter integration between the Skeleton instance and
> an Auxillary member instance, where the Auxillary instance isolates
> behavior that I might want to modify later through inheritance.
>
>class Auxillary (Friend):
>  def  __str__  (self):
>    return "%s %d" % (self.__class__.__name__, self.friend.core_data)
>
>class Skeleton:
>  def __init__ (self):
>    self.auxillary = Auxillary (self)
>
>skeleton = Skeleton ()
>
>print skeleton.auxillary

This looks just like the Strategy pattern except that instead of
storing the skeleton as a value within Auxiliary, you use a 'Friend'
base class. I would argue that this obscures the code rather than makes
it clearer. I would do this sort of thing in C++ where you need that
base class to enforce the interface, but not in Python. I don't care
what type I assign to self.auxillary as long as it supports the
methods/properties I require, and it shouldn't care whether it's being
assigned to a Skeleton or something else, as long as that object
provides the data it requires.

-- 
Ben Sizer




More information about the Python-list mailing list