OO

[Paul Prescod]

Egbert Bouwman wrote:
> 
> ...
> 
> Actually a great eye opener was the remark in this list a few days ago,
> when someone said that you use classes when you have to combine
> program and data, and functions when you have only program code.

Let me be more explicit about this. Classes are important when you want
behavior to travel *with* the data. Procedural and functional styles are
used where you want to impose behavior on "dumb" data. Real programs
tend to use both styles. Often a procedural model is used to get data
into the program where you combine the data with behavior in objects.

When the behavior travels with the data (as methods), you can fiddle
with the data without thinking much about its underlying implementation
(through the methods). Therefore that underlying implementation can be
really, really complex or really really simple and you don't care. It
can also change between versions of the module and you still don't care.
That's the encapsulation part of OO. You can actually do this pretty
easily just with just functions (not methods), using a style of
programming like this:

obj=CreateNewObject()
behavior1( obj, param1, param2, param3, ...)
behavior2( obj, param1, param2, param3, ...)
behavior2( obj, param1, param2, param3, ...)

There are lots of APIs written in this style in non-OO languages. This
is encapsulation (whether done in an OO language or not)

The "polymorphism" part of OO comes from the fact that once you have an
object, you can work on its methods without knowing exactly what kind of
object you have. The Python library has lots of good examples of this
but here's a beautiful example:

class myOutputClass1:
    def write( self, data ):
        ...write it to a GUI window....

class myOutputClass2:
    def write( self, data ):
        ...write it to a log ....

class myOutputClass3:
    def write( self, data ):
        ...send it via email to Bill Gates....

Now I can say 

sys.stdout=myOutputClass1() 

and hundreds of pieces of code that were supposed to work on the stdout
"stream" will magically work on myOutputClass. When they say:
sys.stdout.write( "foo" ), it calls the appropriate write method.

The fact that it has the right methods is enough to make it "stand in"
for a stream. This is much harder in a non-OO language because you have
to "fake" the objects carrying around their behavior as methods. I think
that polymorphism is really the heart of OO in Python. It's so important
that some separate it out from the other OO stuff and just call it
"genericity."

The third part of OO is most emphasized in most non-Python languages:
inheritance. Inheritance is a way of extending existing objects so that
you do not have to write all of that code over again. In other
languages, inheritance takes on some more mystical properties for the
type system, but you could be a decent Python programmer and only use
inheritance very, very rarely.

According to the powers that be, these are the three main features of
OO: encapsulation, polymorphism and inheritance.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski