× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: >>> Chris Rehm <Mr.AS400@ibm.net> 02/20/98 08:37am >>>
  • From: Scott Cornell <CORNELLS@xxxxxxxxxxxxxxx>
  • Date: Fri, 20 Feb 1998 12:34:03 -0500

>>> Chris Rehm <Mr.AS400@ibm.net> 02/20/98 08:37am >>>
** Reply to note from boothm@ibm.net Thu, 19 Feb 98 20:29:29 -0500

>> What about a "one paragraph detailed summary report" on what the most 
>> visible difference is in a old fashion vs. an OO fashion would be?

>You tell two programmers to "program" making a cup of tea. 

>The first programmer, procedural, writes the steps from beginning to end
<snip>

>The second programer is OO, he goes to the cup and says, "Give me tea."

                 -----------------------------------

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:

The procedural programmer writes steps to build the coffee machine, fill it 
with hot water, dip the tea bags,
etc., which works just fine.  But, when he's asked to make a cup of coffee, he 
repeats the process...OK, if
he's smart, he reuses his tea machine code & just makes needed changes.  But he 
still ends up with 2
seperate program objects.  Now, users ask for additives in their drinks - the 
tea machine might have a LEMON
Y/N switch, while the coffee machine would probably have CREAM Y/N - thus, 2 
programs to modify, 2 places
to introduce bugs.  Request for pop machine (soda to non-Midwesterners) results 
in ... and so on.

(wierd OO terms in all caps)
The OO programmer writes an OBJECT CLASS "Beverage Machine"  (or better yet 
uses one someone else
wrote) that does all the things a beverage machine should do:  it might have a 
PROPERTIES for drink type
(COFFEE/TEA/MT DEW) and temperature (HOT/COLD/TEPID/SCALDING) and a METHOD for 
pouring, among other
things.  He then creates an INSTANCE of "Beverage Machine" called "Tea Machine" 
& sets the property of
drink type to TEA - this is usually the drag & drop, paint the thing on the 
screen interface.  He doesn't care
how "Beverage Machine"s make tea, nor does he care how they pour the beverage 
into a container...in fact,
he can't find out, even if he wanted to - that's INFORMATION HIDING.  The 
entire job of coding the "make a cup
of tea" app consists responding to an EVENT, maybe a button click by the user, 
by executing "Tea Machine"'s
pour method.  If the user wants iced tea as opposed to hot tea, he clicks maybe 
a radio button - the event
code simply sets "Tea Machine"'s temperature property, nothing more.  Same 
story for "make a cup of coffee"
- instance of "Beverage Machine" called "Coffee Machine", set beverage type to 
"COFFEE" and voila - the same
user interface code for "tea machine" works for "coffee machine."  And, when 
users ask for additives to their
tea or coffee, our OO hero does NOT change "Tea Machine" or "Coffee Machine" - 
he adds a property to
"Beverage Machine" called additive (LEMON/CREAM/SUGAR) and a method called 
include_additive.  Both
"Coffee Machine" and "Tea Machine" automagically INHERIT the new property 
additive and the new method
include_additive, because they are CHILD INSTANCES of a PARENT CLASS.

that, in my humble and most uninformed opinion, is the gist of it - reuse code, 
hide information, object
heiarchies, etc.  All in all, if one is a GOOD disciplined procedural 
programmer, I would think one would
have no trouble doing OO well - maybe someday I'll get a chance to try myself 
(pre-supposing I'm a good
procedural programmer of course ;))

Scott Cornell
Mercy Information Systems
+---
| 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
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.