Re: OK, What's OOP? (kinda long and tech

["Gallagher, Susan" <sgallagher -at- STARBASECORP -dot- COM>]

On Wed, 18 Oct 1995, Gallagher, Susan (that's me)  wrote:

> >>     asset. Experience in OOPS is essential.

> >Anyone know what OOPS is?

> >Greg

> They're asking for experience with object-oriented programming. The 's' is
> the oops part.  ;-)


And Bobby Collins responded with...
>OK, I'm curious. What is object-oriented programming?

I'll try to be as succinct as possible, but that's a broad question! If
you're not interested, hit the delete key now!

Object-oriented programming is a programming technique (like structured
programming is). When you program in an object-oriented language (such as
C++ or Smalltalk), each data element is an object of a particular type or
Class (number, string, array, etc.). All objects of a particular class
understand the same messages.

Object-oriented programs are event-driven -- that is, they (usually) wait
for input before they perform an action. So, the user double-clicks on an
icon or enters data into a field and clicks OK. This sends a message to an
object. If the object understands this message, it performs the required
action according to the 'method' defined by the message. If the object does
not understand the message, it produces an error.

Each object within a class may have a different method of responding to a
message. The sender of the message does not have to worry about the process
by which the object produces the return value -- only that the object
understands the message and returns a value.

For example--
I'm an object of class person and so are you. An action sends us the
message, "What is your age?". I may arrive at my age by remembering the year
I was born and the current year and doing the math. You may arrive at your
age by memory, or by subtracting 25 from your mother's age, or by some other
process. The sender of the message doesn't care *how* we arrive at the
answer as long as we send back the return value of our age.

There can be many subclasses of a class. For example, in class person, there
are subclasses techwriter and novelist. Both subclasses *inherit* certain
methods from class person, such as getName, getAge, type, edit, etc. --
however, the method writeBook is understood by both subclasses but processed
very differently.

Object-oriented code is -- when it's done well -- easier to maintain and
more reusable than structured code. When you change a module in a structured
program, you probably need to change all of the code that references that
module as well. Not so in oo code. For example, if you're writing code for a
menu, the structured code may look like this...

(selection)
case 1
   do 1
case 2
   do 2
case 3
   do 3
endcase

if you add a menu option between 2 and 3, you need to change the case
statement to reflect the new item and the new position of the items that
follow it. You may also need to change the name or references in the
routines that the menu selections call.

If you're writing the same code in an oo program, it may look like this.

menu
   getValue (where value is open, edit, cut, copy, paste, etc.)
  doValue (send the message that corresponds to the value, whether its open,
edit, cut...)
end

methods named open, edit, cut, copy, paste, etc. exists with the actions to
be performed when the message is received. If you add a new menu item, you
add a method with that name and the action to be performed. The menu
selection code doesn't need to be changed. It just accepts the new value and
calls the new method.

Of course, there's a lot more to it, but that's the general idea. Hope this
has helped.
It's a really interesting subject.

****************************************************
Sue Gallagher
StarBase Corp, Irvine CA
sgallagher -at- starbasecorp -dot- com
****************************************************