Design: Idiom for classes and methods that are customizable by the user?

[Gregory Ewing]

Dirk Bächle wrote:

> What happens now and then is, that users are unhappy with the way this 
> Taskmaster proceeds. One peculiar detail is, that our "default" 
> Taskmaster always deletes the old target file before re-building 
> it...and in special situations this may be seen as unwanted.

I'm not convinced that replacing the Taskmaster for the entire
build is the right way to address this kind of thing. What if
you want to override that behaviour for some targets but not
others? A single object that controls behaviour globally
makes things inflexible. (Distutils suffers from this problem
with its "command classes" that can only be overridden in their
entirety or not at all.)

It seems to me that it would be better for the Taskmaster to
delegate as much behaviour to the Nodes as it can, and provide
a way of designating which Node classes to use for particular
targets.

I'd even suggest that *all* of the build logic should be in
the Nodes, and the Taskmaster class shouldn't exist at all.
The top level logic should just tell the final Nodes to bring
themselves up to date, and they recursively do likewise for
their dependent nodes.

> I'm currently following the "Factory" pattern (more or less) as I know 
> it from C++ and similar languages.

This statement sets off alarm bells for me. If you're using some
design pattern in Python just because you learned to do it that
way in C++/Java/whatever, you're probably making it more
complicated than it needs to be.

-- 
Greg