Why OOP? - What the heck is OOP anyway?

by Russ Eggen

Published 1997-07-01    Printer-friendly version

When I talk to others who do not know what OOP is, I usually get a blank stare. Then they ask, "Why OOP?". My answer is "Why not OOP?". Now, for someone who does not clearly understand what OOP is, lets get some quick definitions.

OOP -- Acronym for Object Oriented Programming.

OK, that is clear as mud. I also discovered that not very many people understand what the term "Object" means. Many have a wrong definition of this word (as I did). I used to think that these are the files that a compiler wrote (myapp.OBJ). So what am I supposed to do with those? Jeez! Ain't my life already difficult?

Lets clear this word up so we can proceed (there are people in line you know). The term object, in this case means "anything that is visible or tangible and is stable in form, anything that may be apprehended intellectually".

Wait! That sounds like the plain old dictionary definition! It is! This definition works very well for our purposes. So to wrap this up and move on, we are dealing with programming with objects. This is not a new language, OOP is a style of coding, thus the term, Oriented. It may amaze a few people that Clarion has been using some of the style of OOP for quite some time!

As with any new subject, new words are used. OOP is no exception. To master a new subject, one must understand them. Instead of just throwing a bunch of words and definitions at you, I would rather clear up new words as we encounter them, thus keep moving along.

I mentioned previously that OOP is a style of coding. This means that one can use it or not. However, before throwing this concept in the recycle bin, lets answer the first question, "Why OOP?". Many very good Clarion programmers have asked this question and may not have received a satisfactory answer.

My answer is that OOP excels in maintaining your applications, thus efficiency is brought into play. Why? Re-usability comes to mind. Consider the browse procedure. This is the single, most complex (meaning made up of many parts) procedure in the Clarion arsenal. Just look at all those routines! They call other routines that call other routines, etc. This is very hard to find a problem. If you hand code, one must take into account all the little things that a user could do. What happens if the user presses the PageDn key? Or clicks on a different tab? How about if the user does some edit on a record? That is pretty complex right there. And to make matters worse, you must code this stuff for every browse procedure in your application! (Do you hand coders feel writer's cramp coming on?)

How to tame the browse? OOP to the rescue!

Suppose, that all functions that the browse needs to do are kept in one place instead of every browse procedure in your app? The only thing that you need to do for every browse is to maintain what is unique to that browse. All the common code is stored in one place. Now lets pretend that there is a problem when the user presses the PageDn key. Where do you look for the bug? Since this is common for all browse code, the last place you look is in the browse procedure! Huh?

Why not look in your common code bucket? Common code bucket? OK, new term time. In OOP, this is known as a class. A class is defined as "a number of persons or things regarded as forming a group by reason of common attributes, characteristics, qualities, or traits; kind, sort." So we have a browse class. We know that all browse procedures have code that is always the same. Only how it is applied is different, i.e., which files, fields, will the browse work with?

OK, I will concede this point. You can find problem areas faster. Wait, there is an added side benefit: Any object used in your browse (or other procedures) will be linked in only once! This means that your executables are going to shrink dramatically, while retaining all functionality! No more code bloat. With OOP, you can now keep all your common code in an "object pool", so to speak.

With our smart linker technology, we do not copy objects or classes as with other languages. We avoid linking in methods that are not used. This allows you to use pieces of a complex object. Other languages suffer horrible bouts of code bloat. There is no real good reason for this as it is utter waste.

Getting back to maintainability, if you discovered a bug in the traditional style, would you not have to go back and fix every browse in your application? Maybe, maybe not. Not a pleasing thought, regardless! If this were an OOP application, then your search for where the problem is in one of two places, the browse class (where all your browse code would not be working as expected) or just that browse procedure. Either way, your search is short.

OK, I am with you so far, but I am not convinced yet. How does one reuse the common code for each instance of a browse? I assume that is how the new Clarion templates handle this. Right you are! But let me remind you that this is not just Clarion, but a style of coding. Lets get into some simple code to illustrate this point and define a new word along the way.

In "traditional" Clarion, consider this code (borrowed from the Clarion Help file):

App1    APPLICATION('Hello')
        END
App2    APPLICATION('Buenos Dias')
        END

        CODE
        IF CTL:Language = 'Spanish'     !If Spanish language user
          AppRef &= App2            ! reference Spanish application frame
        ELSE
          AppRef &= App1            ! else reference English application frame
        END
        OPEN(AppRef)                    !Open the referenced app frame window

OK, that I understand, as that is how I have been coding for some time. How is something "OOPed?" Good question. Let's begin by using another example:

Animal  CLASS
Feed      PROCEDURE(SHORT amount),VIRTUAL
Die       PROCEDURE
Age       LONG
Weight    LONG
        END

Cat Animal      !New instance of an Animal CLASS (implicit LIKE)
Bird Animal     !New instance of an Animal CLASS

In this example, we start by declaring a class. In our example, this is a structure. We know this as it must have an END statement (which all Clarion structures have). Now this really looks weird, do I see two procedures in a structure that looks like a queue?

Indeed you do. Before we go on, lets see if we can clear up some of this fog. This structure contains data (as our LONG variables show), which we call properties and they contain operations (that's the two procedures). Even though we could use procedures or functions, these operations are called methods.

A property can thus be defined as data or characteristics. A method can thus be defined as something that is done, i.e., in Clarion, a procedure or function. Since we are trying to take the mystery out of OOP, we do need to learn some of the OOP terms. So to put it back to Clarion terms, any simple data type or reference variable are properties. All procedures and functions declared within a class structure are methods.

The Cat and Bird are simple object declarations and is a very good example of encapsulation. This is an OOP term. Encapsulate -- to make, form, or place in or as in a capsule.

Why is encapsulation so important? Because we can treat the object as an entire entity. We can use it without necessarily knowing everything about it. Each object (the Cat and Bird) gets its own set of properties, but shares all the methods. Here is an example:

CODE
IF SomeCondition
  AnimalRef &= Cat  !Reference the Cat
ELSE
  AnimalRef &= Bird !Reference the Bird
END
AnimalRef.Feed(10)      !Feed whatever is referenced

So what is this code saying? If SomeCondition is true, then we are going to feed a quantity to the cat, otherwise we are going to feed the bird. Since we really do not need to know what makes up the Cat or the Bird, we can treat them the same.

OK, I think I follow this, but I do not understand what the period is doing in Animal.Feed. What does that mean?

Good question! In OOP, a period syntax is used in other languages. This reads like an English language sentence, i.e., noun+verb. We know that AnimalRef will either be "cat" or bird". We also know that cats and birds have to eat in order to survive. So "Feed" is a method to ensure survival. So in plain English, AnimalRef.Feed(10) means "Feed either the cat or the bird 10 units of food."

I see! That is very clever! However, looking back at the object, I see there is a procedure, er.. method, that we did not use. Why is it there if we are not going to use it?

Who said we weren't? This goes back to our encapsulation discussion. We do not have to know all the methods about an object to use it. In Figure 3, we have perfectly good code. If we wanted to use the other methods, we could have. Since the purpose of this article is to orient you to OOP, this would be a good time to add to our example code and use the other method. However, this is a pop-quiz! How would you use it? (Sorry! No answer will be given - that would be cheating! OK, OK! Here is a clue -- what would happen to a bird if fed to a cat?)

Everybody still awake? Now lets get onto something interesting (and a new term). Suppose we want to use the Animal Class, but we want to add to it, make it a bit more robust. Do we need to declare everything all over again? Nope. We just declare a new class, adding only the new stuff we want to use. Lets do that now.

Transport        CLASS(Animal)
Run               PROCEDURE(SHORT amount,STRING Msg),VIRTUAL
Sleep             PROCEDURE(SHORT amount)
Direction         STRING(s6)
Speed             SHORT
Duration          SHORT
                END

Horse           Transport       !Declare an instance of Transport
Elephant        Transport       !Declare an instance of Transport

What do we have here? If you notice that we have now declared a new class that has a baseclass of "Animal". "Transport" (the new class) inherits all the data members and methods of the base class. This is called inheritance. Both Horse and Elephant inherit all the properties of the Animal class, in addition to everything in the Transport class.

We know that as with the bird and the cat, both eat, they will eventually die (methods), and they have an age and weight (properties). However, Horse and Elephant can do more, the can Run and Sleep. And we could write some code that would tell either the Horse or the Elephant to Run (how fast in which direction).

If we were to define this in non-OOP terms, then we could use LIKE to get the data portions of Animal, but we would need to define procedures for each time we want to do something with an animal. With OOP, we define it once and then re-use it to suit our needs.

Remember the earlier browse discussion? For every browse procedure we need in an application, we need to define again all the procedures, structures, etc. In OOP, we do this once and then inherit the objects we need to use for our particular task. Inheritance is a very powerful concept and a great shortcut!

One good rule of thumb on inheritance: Use it only when needed! As you can see, there really is no limit on how many new classes one can make. One can go overboard and use too many, most likely caused by not designing a base class efficiently. This can have the effect of unreadable code that cannot be debugged easily, defeating one of the great features of using OOP. When you do use it, and use it well, coding is also fun! You'll know when you use it right.

There is much more to OOP than this, and I have only covered the basics. Since the purpose of this article is a bit of orientation, this is about as far as we need to go to achieve this. We answered the question, "What is OOP?", learned what a method and property are and use encapsulation and inheritance with some very simple code.

In future articles, we will explore the depths of OOP (but at a very easy gradient!). We will also learn new words (yes, there are more) and show some Clarion code so that one can see how this is done. As Clarion 4 nears its deployment, it would be prudent to discuss how to port a structured application to OOP style. There is a good body of data to go over, but not to worry, we will take it one step at a time, and get you there safely and quickly. While we are at it, lets have some fun too!

Until next time...

Printer-friendly version

Copyright © 1999-2008 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.

Clarion Magazine ISSN 1718-9942