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

[Kent Johnson]

Andrew P wrote:
> 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 :)
> 
> The code at the bottom was taken from the OOP chapter, it's a solution
> to one of the end-of-chapter problems.
> 
> Honestly, this toy program is enough to make my head spin.  Am I too
> stupid for OOP?  Here is me trying to decipher it:

You did a pretty good job!
> 
> Which is just entirely too much for my brain to hold at once.  I'm
> sorry if this sounds like whining, but this entire program seems as
> bad as trying to decipher the GOTO-crazy scribblings of a lunatic. 
> There is no linearity, and the extra abstraction of the classes just
> adds another layer of complexity.  Instead of functions and arguments
> there are methods, classes, and instances being passed about
> willy-nilly and no (for me) easy way to follow the path or make sense
> of it.

I agree with the other posters that this is not a very good example of OOP. It shows some of the nuts and bolts of OOP - objects containing objects, invoking methods on objects and dividing responsibility between different classes - but it doesn't use them well and the motivation is lacking.

Fundamentally classes are a way to package state (variables) and behaviour (functions) into a single abstraction. Done well, the resulting class has a coherence and utility of its own.

For simple examples just look at Python's built in string, list and dict classes. In each case, the class hides considerable complexity and provides a useful abstraction. You can use a list without worrying about the details of how the list items are stored, how the storage is allocated, what happens when new storage is needed, etc., etc. You have at your disposal a sort() algorithm that has been tuned for high performance by top-notch programmers over many years, and much more.

You can also think of classes very pragmatically, as another tool available to organize your code, just like modules and functions. Classes add some useful capabilities to your toolkit. This essay gives some simple motivating examples of why a beginner might want to use classes:
http://personalpages.tds.net/~kent37/blog/stories/15.html

> 
> 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?  Are there tools that make reading
> something like this more clear?

There is a very real cost to OOP that responsibility for some action can be distributed among multiple cooperating classes, so to trace through an operation you may have to follow a chain from one class to the next. When the design is well done, the benefit of useful abstractions outweighs this cost. Done poorly, you can write object-oriented spaghetti code. The key is to have a clear idea of the responsibility of each class. 

Stepping through the code in a debugger can be useful to understanding the flow.

Kent