What's object-oriented?

[Martijn Faassen]

zoodoo <zoodoo at infantry.com> wrote:
> What's the concept/logic behind object-orientation? What is it suppose to
> mean?

People noticed that good procedural programs often worked this way:

 * You have defined a bunch of data in a structure. In C, for instance
   this is a struct definition. In many languages these are called
   'records'.

 * You have a bunch of functions that operate on this data.   

The program would then be composed of modules, each defining a data
structure (or bunch of related ones) and the functions operating on
them (creating them, changing them, querying information in them).

Good procedural programs tend to look this way, because they're 
more modular and easier to understand and modify. (this type of
modelling becomes especially obvious when you're writing a simulation
or a game, but it is useful in many places).

So, what we have here is data, and behavior, associated together. It's
not hard to treat this as an object; an object can be seen to have
attributes (data about it), and behavior (the functions/procedures).

Now, many objects are similar in data and/or behavior (or at least
aspects thereof). I can 'throw' a stick, but I can also 'throw' a rock.
In procedural programming you can write a throw() function that works
on both sticks and rocks, but it's a bit tricky:

def throw(object):
    if object.type == "rock":
        ... do the rock throwing thing
    elif object.type == "stick":
        ... do the stick throwing thing

and each time you add a new type of throwable object, you have to extend
the throw() function this way, and all other functions that you may execute
for both rocks and sticks and this new object as well.

The solution of object oriented programming is called 'polymorphism',
which is basically a trick which allows you to write a separate throw() 
function (but with the same name!) for each object. Then, if you throw()
a rock, the rock's throw function (or method, as we call it in object
oriented programming) is executed, but if you throw a stick or something
new like a cat, the throw methods of these objects are called instead.

Your program doesn't need to know what the object it's dealing with even
is; it'll just try the throw() function and assumes that what this does
is what should happen. This allows for some powerful abilities to create
abstractions (which can increase flexibility and ease of understanding)
in your program.

There's also a thing in OO called 'inheritance' which can assist in all
this; often two types of objects share the exact same behavior. Perhaps
the same type of method (some parabola calculation perhaps) needs to be
called needs to be called for calling rocks and for calling sticks. You
can then use inheritance to make these objects share the same behavior.
But, you could make an exception for cats; when they're thrown they'll
scratch and yowl and turn in the air to come right back at you. :)

This is just scratching the surface of what you can do with these
concepts, but I hope it helps.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?