Rivers of ink have flowed in an attempt to explain how object-oriented technology (OOT) can fulfill the needs of today's programming community. To put all this talk in perspective, let's start with a history lesson.

Once upon a time, "real programmers" were happily feeding hex codes to computers, and the art of programming was born. When someone gave those codes some strange names called-what else?-mnemonics, programming took its first step toward becoming comprehensible. This was the age of Assembler.

Eventually the Assembler building blocks became too small for the ever- expanding programs being written. Thus dawned the era of high-level languages (HLLs); early examples of what we now call third-generation languages (3GLs) include COmmon Business-Oriented Language (COBOL), FORmula TRANslation programming language (FORTRAN), Report Program Generator (RPG), and the Beginner's All-purpose Symbolic Instruction Code (BASIC).

In the years that followed, programmers added fourth-generation languages (4GLs), CASE tools, and software engineering to their arsenal of HLLs. All of these technologies improved incrementally upon the good old 3GLs, but none provided a quantum leap comparable to the jump from Assembler to 3GLs. In other words, the size of the building blocks did not change substantially, but the size of the applications kept increasing.

OOT is nothing but the next logical step in the quest for ever bigger, better, and more efficient building blocks for our software. The intent of this article is to introduce the fundamental concepts of OOT. We'll start with the assumption that the inadequacies of the current ways of building software are well-known and the argument for OOT has been accepted.

The first thing to know about OOT is that it is anchored in two basic principles of software engineering: encapsulation and abstraction.

Let's take a quick test. Can you name six components of the steering mechanism in your car? I don't know about you, but I would flunk miserably. Assume that I give you a list of those components. Can you explain how they work?

I submit to you that if knowledge of what a car is made of and how those parts operate together were a requirement for obtaining a driver's license, traffic would be reduced to a trickle of engineers and commuting to work would be a breeze.

All you need to drive a car is the knowledge of how to operate the controls that make each part of the car do its job. What those parts are made of, how the components are placed, and how they interact is hidden from you. That's encapsulation. In programming terms, encapsulation is the hiding of the data structures and the algorithms used by a procedure from the users of that procedure.

Further, you don't need to know how those parts achieve their tasks. That's abstraction. In programming terms, abstraction defines a procedure only in terms of what it does, hiding how it is done. Note the all-important distinction between "How does steering work?" -which is the algorithm and is hidden-and "How do I get the car to steer?"-which is the interface (and, of course, has to be known to the user).

Encapsulation and abstraction allow car manufacturers to change technology as often as they want without invalidating your driver's license every time. Sure, you'll have to learn a new trick from time to time, but the fundamentals don't change.

Everything we do in life can be regarded as a sequence of interactions between objects, and business activity is no exception. We design applications to solve those business problems, but when we use the traditional development methods, that picture of how objects interact is lost. OOT tries to bring that model back into the world of computer programming. This brings us to the most fundamental OOT question-what is an object and how does it relate to objects in the real world?

The Structure of an Object

An object is a collection of three things:

o A set of data. o A set of operations (procedures) that operate on and only on that data. o A set of rules describing how the object can be used (i.e., how the operations are to be invoked, its interface to the outside world).

If we go back to the steering mechanism of a car, the data would correspond to the actual parts making up a steering mechanism. The operations would be all the mechanical (and maybe electrical) phenomena that cause the wheels to turn, from steering the shaft clockwise or counterclockwise to executing operations like TURN-LEFT and TURN-RIGHT. One could also think of turning as a single operation with one parameter (direction of turning): TURN (left) and TURN (right). To invoke operation TURN-LEFT, rotate the steering column counterclockwise. To invoke operation TURN-RIGHT, rotate the steering wheel clockwise.

The data and the operations are invisible to the user (i.e., they are encapsulated). The rules are visible to the user, and they describe how to interface with the object (abstraction). This relationship is shown in 1.

The data and the operations are invisible to the user (i.e., they are encapsulated). The rules are visible to the user, and they describe how to interface with the object (abstraction). This relationship is shown in Figure 1.

The concept of encapsulation and abstraction is very similar to how we conceive of objects in the world at large. We are surrounded by objects, and we spend a large part of our life studying them in order to understand their characteristics (in OOT, those characteristics are data). Watch a small child make first contact with an object and you'll see what I mean.

While some of the characteristics of objects are fixed, some are not. One reason we interact with objects is because we wish to change their characteristics. In doing so, the objects appear to perform some action useful to our purposes. We turn the steering wheel to get the steering mechanism to change the position of its components and make the car turn. We subject a lamp to electrical current to make it change its physical characteristics and emit light. We press a button on a remote control to cause the TV to change channels. Objects exhibit a certain behavior when requested to do so in some previously defined manner. In OOT, the physical phenomena that change the characteristics of objects are the operations.

The interface is the instruction manual of the object. It describes what the object can do for us and, more importantly, how to get the object to do it. For the steering mechanism, it is turning the steering wheel. For the lamp, it may be flipping a switch or pulling a chain. For the TV, it may be pressing the buttons on the remote control unit. In all cases, the interface rules must be obeyed or nothing will happen. You can talk to a lamp as much as you want; you may get a psychiatric examination out of it, but certainly no light.

Object Type and Object Instance

We are interested in objects because they do certain things we find useful. But how do we determine what objects can do?

You've probably rented a car at some time. Even if you haven't ever seen that model, you can drive it after a cursory inspection of some parts. How is that possible? Well, it's a car! It must have certain characteristics. You quickly inspect the object to reconcile what you know a car must be with the object in front of you, and off you go.

We analyze and compare the properties of the objects around us for the purpose of classifying them and to deduce new and unverified properties. When objects share properties, they are likely to behave the same way when subjected to requests hinging on their shared properties. So if this thing looks like a car, it must have an ignition, a steering mechanism, brakes, an accelerator, and turn signals. It will respond to your input according to the standard interface for a car. This is the concept of object type.

Object type is a category of grouped objects based on a shared set of properties. Type is abstract, present only in our brains, as opposed to the objects that make up the category, which are physically present. There is no such thing as a car object-when it comes down to the object itself, it is my car, or your car, or one of the cars of the rental company. All of them are instances for the category (or object type) car.

In real life, we tend to confuse object types with object instances. Is a TV an object? If you answered yes, think again. A TV is a type of object. My Sony KV41EXR96 serial number 036879 is an object instance.

In a programming environment, it is a lot more difficult to distinguish between the two. As a matter of fact, it turns out to be impossible for practical reasons directly related to the nature of programming.

Object Behavior

Now that we've defined what an object is, let's look at what it can do. The first and most important concept is that an object can only do what it knows how to do. You can try as much as you want, but the VCR won't do your dishes. When objects do something they know how to do, they execute one of their operations.

A request is the process of asking an object to do something (i.e., execute one of its operations). Of course, the request has to be made in strict accordance with the rules (or interface).

Making requests consistent with the interface will in some undisclosed manner cause the activation of an operation (program) available with the object. The operation will change the data in some predetermined-but also unknown-manner, letting the user see only the result of the change.

A request can be initiated by something outside of the object-oriented application itself (such as a user) or by another object in the application. The former is called an external request; the latter is an internal request.

For example, the user requests the object remote control to turn on the object TV set. As a result, the characteristics of the two objects involved may change. The TV is now on, allowing you to execute new operations that were not possible before. On the other hand, nothing changed as far as the remote control is concerned.

Reality Check

The TV example can be applied to the computer world as well. 2 shows the Data Area (DTAARA) object of a familiar programming environment: the AS/400. This object consists of some dedicated storage (or, to be more precise, the contents of that storage). This is the data. It also includes six operations applicable to data areas (Create, Delete, Change, Display, Retrieve, and Work With) and an interface that is the syntax of the six CL commands (CRTDTAARA, DLTDTAARA, CHGDTAARA, DSPDTAARA, RTVDTAARA, and WRKDTAARA).

The TV example can be applied to the computer world as well. Figure 2 shows the Data Area (DTAARA) object of a familiar programming environment: the AS/400. This object consists of some dedicated storage (or, to be more precise, the contents of that storage). This is the data. It also includes six operations applicable to data areas (Create, Delete, Change, Display, Retrieve, and Work With) and an interface that is the syntax of the six CL commands (CRTDTAARA, DLTDTAARA, CHGDTAARA, DSPDTAARA, RTVDTAARA, and WRKDTAARA).

Is this a true object? Let's examine its characteristics.

o Encapsulation of data. The user has no idea where the storage is allocated or how it is structured. Besides the space occupied by the data written by the user in the data area, there may be much more information, such as owner ID, date of creation, date last updated, and access controls. All of this is inaccessible to the user.

o Encapsulation of operations. The user cannot change the implementation of the operations. The user can only understand the interface and issue requests that conform to that interface. As a result, a user can change a data area only in the ways the six commands allow.

o Encapsulation of interface. The user cannot change the CL commands either.

o Abstraction. The CL manual gives the details on what the six operations do, but doesn't say a word about how they do it.

Conclusion: the data areas on the AS/400 are truly objects.

The net effect is that IBM can change anything it wants in the implementation of data areas without affecting the user, as long as the interface and the implementation of operations are both upwardly compatible.

In the above example, the object type is the data area. But what does that really correspond to? Does a type physically exist? If so, in what form?

An object contains data, operations, and an interface. If I have three data areas, the actual code for the six data area operations would be replicated three times, once with each of my three data areas. That's hardly practical, is it?

Of course, it makes perfect sense to store the programs that implement the operations only once, in a place where they are accessible to all the instances of data area. That's where the analogy with real world objects breaks down. A TV set comes with everything needed to accomplish its operations, so it is truly encapsulated.

If OOT objects share their operations, the concept of type now takes up a clear programming meaning: it is the repository of all things shared by all instances of that object type.

From a logical point of view, we still regard objects as having their own private copy of operations. In other words, the sharing is transparent to the user.

3 illustrates object instance implementation and the shared interface and operations for two data area objects. The actual data is different for each data area, but, structurally, they are cookie-cutter copies of each other.

Figure 3 illustrates object instance implementation and the shared interface and operations for two data area objects. The actual data is different for each data area, but, structurally, they are cookie-cutter copies of each other.

Software Implementation

When these concepts are applied to software, they get different names:

o The software implementation of an object is called an instance. Instances are data structures specific to an individual object. For a savings account object, it could be something like owner ID, account number, or balance.

o The software implementation of an operation is called a method. Methods are actually programs. In an object-oriented environment, they are usually written in an object-oriented language like C++ or SmallTalk, but any 3GL could be used as long as the development tool allowed it. In a banking application, examples of methods include open account, close account, and update balance.

o The software implementation of an object type is called a class. Classes are repositories of information that contain everything the objects in the class share-the methods, the description of the data in the objects (not the data itself), and the means to recognize and validate a request.

Confused? Don't be. The idea of different terminology for programming concepts is familiar. For example, when you develop a solution for a business problem, you think about it and describe it as an algorithm. Once you have coded it, you call it a program.

After receiving a request, an instance (or object) asks its class to get a certain operation to perform a certain task. That places a great deal of importance on what is and what isn't a member of a particular class. (I'll cover that in more detail in an upcoming article.)

In the banking example, the savings account class would contain a template describing what kind of data is stored for every instance of a savings account, the actual programs for the methods, and a program capable of receiving requests. The program would determine if a request is correctly formulated according to the interface rules for the methods-open account, close account, and update balance.

What's Next?

Now that the groundwork is done and the fundamentals are clear, we are faced with another set of questions: How do objects relate to each other? Is there any relationship between classes? How can these concepts be put to best use? What is an object-oriented application anyway? How does it work? How are we going to build it? And, perhaps most importantly, how are we going to get there from here? I hope to answer these questions in a future article on the nature of objects.

Making the transition from a traditional 3GL environment to the brave new world of OOT is not easy. It is bound to place you on a steep learning curve and create some confusion. While working hard to turn his company around, General Electric chairman Jack Welch used to say, "If you are not confused, you have no idea what it's all about." I hope you now have an idea of what it's all about.

Rares Pateanu is the manager of RPG development for IBM. He can be reached through Midrange Computing.

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails