Am 02.11.2012 09:08, schrieb Martin Hewitson:
On 2, Nov, 2012, at 08:38 AM, Paul Rubin <no.email@nospam.invalid>
wrote:
Martin Hewitson <martinhewit...@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!
--
http://mail.python.org/mailman/listinfo/python-list
