Removing inheritance (decorator pattern ?)
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
|  comes to mind (not to be confused with the the Python meaning of
| the term "decorator").
|  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
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
More information about the Python-list