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

Andrew P grouch at gmail.com
Fri Oct 21 21:14:00 CEST 2005

On 10/21/05, Kent Johnson <kent37 at tds.net> wrote:

>For simple examples just look at Python's built in string, list and dict

-Using- OOP isn't the problem :)  It's impossible to ignore it's usefulness when
programming in Python.  But getting from there to thinking non-procedurally is,
as has been pointed out, a tiny bit difficult.

My frustration/abject fear was with this particular example being very hard to
decipher, and not seeing any advantages to it being laid out that way.  I
assumed there were some, where this kind of thing had benefits.

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

I realize after all these reposnses that I should have mentioned that  I do use
classes to do exactly that.  Bundle logic and data, but then call the classes
I've made procedurally.  It's handy, having methods attached to objects, and to
be able to use any object that supports the same interface interchangeably.

But I have the nagging feeling I still have it all upside down and inside out.
Writing a bunch of objects that are supposed to interact in dynamic ways at
runtime with nobody leading the band, and all.  Maybe if I'm not writing a
a library or framework I shouldn't worry so much.

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

For all I know people are using IDEs that let them write unreadable code that
simultaneously allows loosest coupling between classes, and most reuse of code
at the expense of readability.  Giant jellyfish-like automatons that are easy
to maintain with appropriate tools.  I'm still not sure that impression is
wrong :)

I do my best learning by reading good examples.  I imagine most people do.
There is just no substitute for understanding what somebody else has done well,
tip to tail.  I am just mistrustful of something so hard to puzzle out.

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

I've never actually used a Python debugger. Or any debugger.  That was such a
commonsense answer I'm embarassed I didn't try it first.

Thanks again, Kent :)

More information about the Tutor mailing list