Helper classes design question

[John O'Hagan]

On Tue, 24 Aug 2010, Jean-Michel Pichavant wrote:
> John O'Hagan wrote:
> > I want to know the best way to organise a bunch of functions designed to
> > operate on instances of a given class without cluttering the class itself
> > with a bunch of unrelated methods.
> > 
> > What I've done is make what I think are called helper classes, each of
> > which are initialized with an instance of the main class and has methods
> > which are all of the same type (insofar as they return a boolean, or
> > modify the object in place, or whatever).
> > 
> > I'm not sure if I'm on the right track here design-wise. Maybe this could
> > be better done with inheritance (not my forte), but my first thought is
> > that no, the helper classes (if that's what they are) are not actually a
> > type of the main class, but are auxiliary to it.

I wasn't subscribed when I posted this question so the quoting and threading 
is messed up (sorry), but thanks for the differing approaches; in the end I 
have taken Peter Otten's advice and simply put the functions in separate 
modules according to type (instead of in classes as methods), then imported 
them. This has all the advantages of using a class, in that I can add new 
functions in just one place and call them as required without knowing what 
they are, e.g.:

options = {dictionary of option names and values} #derived from optparse

for sequence in sequences:
    for option, value in options.items():
        {imported namespace}[option](sequence, value)

but it seems simpler and cleaner.


John