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

[Dirk Bächle]

Hi Gregory,

thanks a lot for your answer and comments.

Am 13.05.2016 um 08:35 schrieb Gregory Ewing:
> Dirk Bächle wrote:
>
> [...]
>
> 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.
>

This is pretty much what we have now, and the starting point for the redesign. Our current Node class already has too much knowledge 
about the build logic, and users frequently complain that it's too hard to derive from our base "Node" to build their own upon.
Our aim is to make the Node class in particular "slimmer", instead of "fatter". ;)

>> 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.
>

Yes, I know what you mean. I used the term "factory" for the idiom of addressing a function or class by a key (=string), and the 
"more or less" was supposed to clarify that I'm not planning to implement a dedicated "TaskmasterFactory" as class...as you'd find 
in a design book when looking up the "Factory" pattern.


It may well be that some of my wordings and expressions are a bit misleading...sorry, I'm not a native speaker.

Best regards,

Dirk