Organisation of python classes and their methods
ulrich.eckhardt at dominolaser.com
Fri Nov 2 11:18:08 CET 2012
Am 02.11.2012 09:08, schrieb Martin Hewitson:
> On 2, Nov, 2012, at 08:38 AM, Paul Rubin <no.email at nospam.invalid>
>> 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
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. 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:
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.
 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!
More information about the Python-list