> 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)
HTH,
Alan G
Author of the learn to program web tutor
http://www.freenetpages.co.uk/hp/alan.gauld
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
