|
** 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 +---
As an Amazon Associate we earn from qualifying purchases.
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.