OOP

[Chris Rehm <Mr.AS400@xxxxxxx>]

** Reply to note from Scott Cornell <CORNELLS@mercyhealth.com> Fri, 20 Feb 1998 
12:34:03 -0500


> I don't do OO coding to any great extent, so this is probably the blind 
>leading the blind.  But, I think the 
> analogy only covers the information hiding advantage of OO, which well 
>structured procedural code has 
> anyway (sorta the point someone made earlier in the thread, eh?)  How about 
>this similar analogy:

Scott, after I finished my email last night I thought it over and realized
that I wasn't being very clear about what I think the tea analogy covers.

If you tell two programmers, one procedural and one OO to write the
program, "drink a sip of tea" and they go to work:

The procedural programmer will begin writing step by step the way to drink
a sip of tea. 

He will define all the variables he is likely to need: tea, cup, teapot,
sugar, spoon, sip, etc. etc.

he will check the cup for tea and if it's empty he will go check the
teapot, and if it's empty he will fill it with water. He will check the qty
of teabags, and on and on. 

We all know how tedious it can be to code what seems like a simple process
to do! Obviously he will copy in the code from that "boil an egg" program
he wrote the other day, and he will copy in the code from the drink coffee
program, but he recalls that a lot of it isn't compatible because coffee
comes from grounds and is percolated and tea comes from leaves and is
steeped. But that's okay, he knows how to make this work.

The OO programmer will write something like:

myCup = new Cup();
myCup.giveTea(sip);

The instance of the class Cup will have all the methods necessary. The work
came in defining the class Cup and all it's super classes and the classes
for the objects used by the instanced of class Cup.

The giveTea method will check to see if it contains enough tea for the
request. If so, it will return the tea and reduce it's quantity by amount
sip. If not, it will call method fillWithTea which will check to see if it
is holding some other liquid and if so call method cleanUp and then method
fromTeaPot which will check/create an instance of TeaPot and send a
giveTea(cup) message. etc. etc.

The point being, the programmer trying to create the drink tea program
needn't be concerned with all this. All of the methods he needs are
prebuilt somewhere. He is just building a program to use those methods.

That sort of points out that with OO programming, the work is in creating
the system. While new methods can be added to classes as time goes by
(tomorrow, we will need to make sure we can send giveTea(sip, iced) as well
as giveTea(sip, hot) without giving up giveTea(sip)) it is important to
design your object classes well so that implementation of the classes is
straightforward and the programmer trying to create applications can do
what they need to.

Does that make more sense?


Chris Rehm
Mr.AS400@ibm.net

How often can you afford to be unexpectedly out of business?
Get an AS/400.
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@midrange.com".
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---