[Tutor] Help(!) with OOP/Composition from "Learning Python"

[Andrew P]

Hi Alan, thanks for taking the time to answer so thoroughly.  I've
responded to a few things below.   But let me say right off I have
gone through the OOP section in your excellent tutor.  It was one of
my main resources learning Python.  I actually have Bertand Meyer's
book here (and have written a couple small programs in Eiffel!) based
on your recommendation, but I think my main confusion is stemming from
composition vs inheritance, and it's effect on program
readability/understandability.  I went to "Learning Python" looking
for that composition example trying to make things a little more
concrete.

On 10/20/05, Alan Gauld <alan.gauld at freenet.co.uk> wrote:

> However its not a terrible example either...
>
> > Am I too stupid for OOP?
>
> Definitely not but for some people OOP is not as naturally intuitive as it
> is to others. For some reason those with a background in math seem
> to find OOP less intuitive, I dunno if that applies to you though :-)

I was referring specifically to being able to follow how the classes
interacted to obtain the results.  I know that objects interact
dynamically at runtime, so there may only be so much I can infer, but
I am trying to read code to get an idea of how to write it, and it was
discouraging to be stymied by an example from "Learning Python",
especially a do-nothing example..

> Absolutely. You are not supposed to try to follow the chain of command
> to the bottom, you are supposed to work with theobjects as stand alone
> mini programs. YOu don;t think about how they work inside any more
> than you read the Python interpreter source code every time you call it
> (I assume you don't do that???!) Objects are tested independantly and
> thereafter we just trust them to do what they claim to do.

How does this relate to composition vs inheritance?  When you have
multiple classes composed of multiple parts of multiple other classes,
doesn't that freeze your interface decisions early on?  It seems to
really tightly bind classes together.  I think I just need to track
down a real-world example, maybe.  This was probably the wrong one to
choose.  I just can't picture how it would even be possible to write
and grow.

Inheritance, subclassing, and overloading are much simpler concepts,
and relatively straightforward to read, at any rate, ignoring design
issues :)  You can point to a class and say ok, this is inheriting
that class's methods, or overloading an abstract class.  Perhaps it's
just the interaction between classes that is giving me a problem.

> > Instead of functions and arguments there are methods, classes,
> > and instances being passed about willy-nilly
>
> There should be messages which include objects as their arguments.
> Its important to conceptually separate messages from methods. We
> send a message to an object and it responds by executing a method
> - which method we mauy not know(this is polymorphism!) - and we
> get a result back. We pass objects around so that the receiving object
> can call methods of that object - this is somewhat akin to passing
> function pointers or lambdas in more traditional languages.
>

I should have been more clear here, as well.  I was talking more
specifically about the example as composition.  I think I am just
missing something conceptually.  I've written basic classes for myself
before that just bundle logic and state, and I think they were
reasonable choices for objects.  But really it was just a way to
interact with an object procedurally, like I do every day with Python.

I'm just not sure how to organize the piecemeal composition of new
classes from existing ones, in any sensical way.  Or for that matter,
how to arrange a bundle of classes with no "leader" :)  Speaking of
structural programming biases.  But at least I recognize that hurdle,
and can see how it would be possible.

> At risk of too much blatant self promotion try the OOP topic in my tutor.
> Also try reading through the Games framework (hmgui.zip) that I submitted
> to Useless Python (or is described in the paper book version of my tutor)
>

Well, that sounds like a real-world example I can look at :)  Thanks
again for your time, Alan.