Removing inheritance (decorator pattern ?)

Terry Reedy tjreedy at udel.edu
Sun Jun 15 22:48:22 CEST 2008


"George Sakkis" <george.sakkis at gmail.com> wrote in message 
news:a39a69df-89d3-4cf0-a06e-3252ed6497af at k37g2000hsf.googlegroups.com...
|I have a situation where one class can be customized with several
| orthogonal options. Currently this is implemented with (multiple)
| inheritance but this leads to combinatorial explosion of subclasses as
| more orthogonal features are added. Naturally, the decorator pattern
| [1] comes to mind (not to be confused with the the Python meaning of
| the term "decorator").
|
| [1] http://en.wikipedia.org/wiki/Decorator_pattern

I read the first part of the article.  The following
"This difference becomes most important when there are several independent 
ways of extending functionality. In some object-oriented programming 
languages, classes cannot be created at runtime, and it is typically not 
possible to predict what combinations of extensions will be needed at 
design time. This would mean that a new class would have to be made for 
every possible combination"

suggests to me that this pattern is not needed in Python, where all user 
classes are created at runtime.  One can define a class factory with an 
'extensions' parameter that creates a class and adds methods according to 
the extensions.  One could even, for instance, start with a basic text for 
__init__, add lines according to the extensions, compile the definition, 
and add *that*.  One could even generate a particularized value for the 
.__name__ attribute.

If it is not important that instances in the general group have different 
__class__ attributes, one might consider a master class with all methods 
and an init function that only adds the data attributes needed 
(borderwidth, scroller state, etc.).

I did not read your toy example enough to quite see how it connected to the 
wiki article.

tjr






More information about the Python-list mailing list