On Monday 23 August 2010, it occurred to John O'Hagan to exclaim:
> 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.
You could try using mixins. I don't know how well this fits with the problem
at hand, but what you'd do is this:
Instead of thinking of the bits you're writing as helper classes, think of
them as more or less isolated pieces of the functionality you'd like the final
object to have. You can implement these independently, operating on self
instead of on self.seq or something like that. Have a look at the abc module
(abstract base classes) for a nifty way to prevent instantiation of these
classes.
If the functionality you're implementing only makes sense for a sequence, or
for a sequence with certain characteristics, you can define an ABC that
represents/specifies those characteristics and inherit from that. Or maybe
not.
Then, you have a bunch of largely independent classes providing isolated
pieces of functionality, which you can then combine into one class by
inheriting from ALL of them, and implementing the missing methods, like a
constructor.
Let's draw a graph:
MySuperDuperCoolSequenceThing
/ / \ \
Filtered Rotated Tap \
\ / / \ |
AbstractSequence KitchenSink
\ /
object
I hope you understood at least a bit of my ramblings.
Cheers,
Thomas
--
http://mail.python.org/mailman/listinfo/python-list
