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

Alan Gauld alan.gauld at freenet.co.uk
Fri Oct 21 01:09:19 CEST 2005

> I've been reading about composition vs inheritance, and went back to
> "Learning Python" to look at something I found very confusing a year
> ago.  Turns out I still find it very confusing :)

I don;t know the example but from the snippetts you've posted it doresn't 
look like a particularly good example of OOD. So that won't help. 
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 :-)

WHen OOP first appeared several studies suggestedit took between 
6 months to 2 years for an established non OOP programmer to fully 
"convert" to OOP whereas complete newbies picke it up in less 
than 3 months... So much of the effort comes in unlearning old habits.

    x = Lunch(  )                       # Self-test code
    x.order('burritos')                 # If run, not imported

Pesonally Lunch is a strange name for a class and order() is not an 
operation I'd assosiate with a lunch object - eat() maybe! These 
are the kind of design issues I referred to above.

 >   def order(self, foodName):      # Start a Customer order simulation.
 >           self.cust.placeOrder(foodName, self.empl)

Again a weird design decision, I wouldn't expect to place an order 
with a customer, I'd expect that to be on the waiter object. I would 
expect to see a customer send a messaage to a waiter asking to place 
an order for a Lunch.... And the Lunch would comprise several 
courses/foodstuffs. Again a weird OO design IMHO.

> def placeOrder(self, foodName, employee):  # Place order with Employee.
>        self.food = employee.takeOrder(foodName)

Now here we have the empoyee taking the order, that makes more sense.

> x.result(  )

And what exactly a Lunch object doesin response to a result message 
I have no idea, again a badly chosen method IMHO.

> Which is just entirely too much for my brain to hold at once.  

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.

> bad as trying to decipher the GOTO-crazy scribblings of a lunatic. 

Not so because at least there can be no returns from the middle of 
blocks etc...

> There is no linearity, and the extra abstraction of the classes just
> adds another layer of complexity.  

You are right that there is no linearity. Thats one characterisatic of an 
OOP programme. The structure is a directed graph of object 
relationships with messages passing between objects along the 
connecting lines. It is not a heirarchical tree structuire as found 
in structured programming.

> 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.

> no (for me) easy way to follow the path or make sense of it.

You cannot easily do that without specialised debuggers such 
as "Look!" etc OOP works on the assumption that you debug 
one object at a time and rarely need to follow the code to 
understand whats happening. In the example given it looks like 
the object lattice and method names are not too intuitive.

> Is this just an example of a technique with a constant complexity
> factor that looks ridiculous on a toy program, but very quickly
> becomes useful on larger ones?  

Thereis a huge amount of trith in that too. I rarely use OOP on 
programs of less than 50 -100 lines but beyond that size and 
the use of OOP really kicks in. By the time you have 
10,000+ lines OOP becomes very powerful.

> Are there tools that make reading something like this more clear?

There are many tools but most are commercial. I mentioned the 
Look! debugger for C++/Java and SmallTalk. Borland and Microsoft 
both provide message visualisation tools too. Many OOD CASE tools
provide simulation tools for testing s design prior to generating code.

Don't give up hope but rather try to live in faith for a spell.
Ty to find some other examples of Python OOP too, I don;t personally 
like the look of the Lunch example. One of the key features of a good 
OOP programme is that each object should have clear reponsibilities
and those should be exposed as the objectsinterface. These objects 
look like they aren't quite sure who orders what!

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)


Alan G
Author of the learn to program web tutor

More information about the Tutor mailing list