Organisation of python classes and their methods

[Ulrich Eckhardt]

Am 02.11.2012 09:08, schrieb Martin Hewitson:
> On 2, Nov, 2012, at 08:38 AM, Paul Rubin <no.email at nospam.invalid>
> wrote:
>> Martin Hewitson <martinhewitson at mac.com> writes:
>>> So, is there a way to put these methods in their own files and
>>> have them 'included' in the class somehow? ... Is there an
>>> official python way to do this? I don't like having source files
>>> with 100's of lines of code in, let alone 1000's.
>>
>> That code sounds kind of smelly... why are there so many methods
>> per class?
>
> Simply because there are many different ways to process the data. The
> class encapsulates the data, and the user can process the data in
> many ways. Of course, one could have classes which encapsulate the
> algorithms, as well as the data, but it also seems natural to me to
> have algorithms as methods which are part of the data class, so the
> user operates on the data using methods of that class.

This is largely a matter of taste and a question of circumstances, but 
I'd like to point out here that your "natural" is not universal. If you 
take a different approach, namely that a class should encapsulate in 
order to maintain its internal consistency but otherwise be as small as 
possible, then algorithms operating on some data are definitely not part 
of that data. The advantage is that the data class gets smaller, and in 
the algorithms you don't risk ruining the internal integrity of the used 
data.

Further, encapsulating algorithms into classes is also not natural. 
Algorithms are often expressed much better as functions. Shoe-horning 
things into a class in the name of OOP is IMHO misguided.

Concerning mixins, you can put them into separate modules[1]. If it is 
clearly documented that class FooColourMixin handles the colour-related 
stuff for class Foo, and reversely that class Foo inherits FooShapeMixin 
and FooColourMixin that provide handling of shape and colour, then that 
is fine. It allows you to not only encapsulate things inside class Foo 
but to partition things inside Foo. Note that mixins are easier to write 
than in C++. If the mixin needs access to the derived class' function 
bar(), it just calls self.bar(). There is no type-casting or other magic 
involved. The same applies to data attributes (non-function attributes), 
basically all attributes are "virtual". The compile-time, static type 
checking of e.g. C++ doesn't exist.


>> Python lets you inject new methods into existing classes (this is
>> sometimes called duck punching) but I don't recommend doing this.
>
> Is there not a way just to declare the method in the class and put
> the actual implementation in another file on the python path so that
> it's picked up a run time?

To answer your question, no, not directly. Neither is there a separation 
like in C++ between interface and implementation, nor is there something 
like in C# with partial classes. C++ interface/implementation separation 
is roughly provided by abstract base classes. C# partial classes are 
most closely emulated with mixins.

That said, modifying classes is neither magic nor is it uncommon:

   class foo:
       pass

   import algo_x
   foo.algo = algo_x.function

Classes are not immutable, you can add and remove things just like you 
can do with objects.


BTW: If you told us which language(s) you have a background in, it could 
be easier to help you with identifying the idioms in that language that 
turn into misconceptions when applied to Python.

Greetings!

Uli

[1] Actually, modules themselves provide the kind of separation that I 
think you are after. Don't always think "class" if it comes to 
encapsulation and modularization!