[Tutor] OOP programming principles overview?

Kirby Urner urnerk@qwest.net
Tue, 20 Nov 2001 16:52:33 -0800


>
>Worst of all is that I am sure that it is easy to understand, and
>I find it very frustrating.
>
>Thanks to all of you.
>
>  ___    | Dubuquoy-Portois
><*,*>   | G.-Joachim L.
>[`-']   | gjl.dp@laposte.net
>-"-"----| <http://allesgut.levillage.org/>

If you forget about programming for a moment, and just think
of yourself as an instance of the class Human, a subclass of
Mammal, in turn a subclass of Chordate, then you've got the
right frame of mind for OOP.

As an instantiated object, you have a personal dictionary
of one-of-a-kind attributes and tweaked methods, but a lot
you can take for granted (your consciousness thread relies
on an API, like internal digestion, without contributing in
any way to the design, which is inherited).

This "I am an object" paradigm is apropos in Python given
the keyword 'self' (actually, any word will work, as it's
positionally defined, i.e. any string will work if positioned
the same way -- but we use 'self' by convention).

The OOP books I've seen rarely teach the first person approach,
but it's really useful:  "I am an altimeter object, what API
to I export to my clients or users?"...  "I am a [fill in the
blank]".  The class definition is like my blueprint.  I have
properties and methods, accessed as self.property1,
self.property2 and self.method1(args), self.method2(args) etc.

A subclass takes a pre-existing blueprint and says "all of
the above, except over here, I want you to replace the generic
X with Y" and so on, i.e. a subclass further customizes and
refines a superclass, but anything not spelled out simply
defaults to the super's behavior...

Well, lest I spiel on and on, I should self.endchatter().

Kirby