In a previous article (see "The Nature of Objects," MC, May 1995), we discussed the fundamental concepts of object-oriented technology (OOT). In a nutshell, an object is a capsule containing data, operations, and an interface to those operations. The interface is the abstract definition of how to use the object. Encapsulation prevents access to the object by any means other than the defined interface. Objects react to requests, which cause the execution of one of the object's operations. We have also seen that, for practical reasons, operations and interfaces are shared by objects of the same kind, so the abstract concept of class now has a very concrete meaning: a repository for the stuff shared by objects of the same type.

So, what really happens when an object receives a request is that the object turns to its class and says "Hi! I am an instance of yours, so will you get such-and-such operation to do its thing to me?" That places a lot of importance on who is and who isn't a member of a particular class.

Classes and Inheritance

How did we arrive at the definition of a class? By looking at shared properties. Consider this property: "Can receive a video signal and use it to reproduce an image on a screen." Clearly, all objects that satisfy this property belong to a class we call TV. What if we now consider a new property? Two things can happen:

1. All the objects in the class also satisfy the new property (e.g., "Requires electrical current to function"). Since the new property applies equally to all the objects in the class, it can be treated as a defining property of that class.

2. Some objects satisfy the new property, while some others don't (e.g., "The image is in color"). This is what we call a differentiating property because it splits the class into two subclasses: one for the objects that satisfy the new property (color TVs) and another for those that don't (black-and-white TVs). When related to the subclasses, the original class is called a superclass.

As we consider more and more properties, we could split our objects into more and more subclasses, in effect creating an entire hierarchy of classes. How does that affect sharing? Clearly, the instances of a subclass continue to have all the properties of the superclass (subclassification adds properties; it does not eliminate them). A color TV continues to "require electrical current to function" and "can receive a video signal and use it to reproduce an image on a screen"; and, of course, so does a black-and-white TV.

This is called inheritance: all the operations of a class apply equally to all the subclasses of that class. The beauty of this concept is that whenever a new operation needs to be added, simply placing it in the appropriate class in the hierarchy will immediately apply it to all the objects in that class and to all the objects in any of its subclasses.

What a powerful (and, hence, dangerous) way of making global changes! Of course, a subclass can have new properties, specific only to that particular subclass. It works a bit like real life: while we inherit some of the genetic properties of a parent, we do end up having characteristics of our own.

Let's look at an AS/400 example. 1 represents a small section of the class hierarchy in the AS/400. Note the base class at the top. This is one class you have not encountered so far, but all the other classes in the diagram are surely familiar to you. Base is what we call an abstract class; i.e., a class that has no actual instances of objects, but acts as a repository for the operations and interfaces that apply to all the objects in the hierarchy.

Let's look at an AS/400 example. Figure 1 represents a small section of the class hierarchy in the AS/400. Note the base class at the top. This is one class you have not encountered so far, but all the other classes in the diagram are surely familiar to you. Base is what we call an abstract class; i.e., a class that has no actual instances of objects, but acts as a repository for the operations and interfaces that apply to all the objects in the hierarchy.

A number of operations can be applied to all the objects on the AS/400. I chose the Rename Object operation with its interface being defined by the CL command RNMOBJ. On the next level, one specific kind of object is a file. Again, many operations apply to all kinds of files, one being Display File Description with its interface DSPFD.

Among the many kinds of files, I picked DSPF (display files) and SAVF (save files), and one sample operation and interface for each file type. The actual file instances might be FRED, WILMA, and BARNEY.

Operations defined for a class apply to all subclasses: e.g., RNMOBJ applies equally to files, libraries, programs, display files, and save files; DSPFD applies to display files, save files, and all other types of files. Let's say IBM needs to add three new fields to the file templates. By changing the DSPFD operation, all kinds of files will now be displayed including the new fields. Of course, if we make an error changing the DSPFD operation, you may not be able to display any kind of file.

Because operations are shared, it makes sense to move them to the highest level in the hierarchy where they still apply. In other words, the class hierarchy determines how code gets shared, so a good hierarchy will give you good code sharing.

As a result, when an operation is requested for a particular object, the object will first ask its class to supply the requested operation. If the operation is not found there, the search continues with the next superclass, and so on until the operation is found.

More on Inheritance

Whether from a genetic or a material point of view, we inherit not only from one parent, but from both, and when it comes to inheriting property, a rich uncle won't hurt either. Is this kind of multiple inheritance possible in the world of objects? The answer is yes. The class TV can be a subclass of electronic device, and it can inherit all the properties of electronic devices. At the same time, TV can be a subclass of entertainment device and inherit its properties, too. For the mathematically oriented, the hierarchy no longer looks like a tree, but is now a graph. This complicates the search for an operation: if a certain operation is not found in the TV class, an arbitrary decision must be made as to which of the superclasses will be searched next. Further, let's assume we chose the entertainment device superclass and that we can't find the requested operation. We must remember that we could have chosen the electronic device superclass and go on to search that sequence of superclasses as well.

While this mechanism perhaps makes inheritance more complex, it makes inheritance much more powerful as well. Having the right hierarchy driving the right inheritance is extremely important. It is so easy to mess it up.

There are a few more problems to sort out when it comes to inheritance (just as in real life). First, consider the case of class A with three subclasses?A1, A2, and A3. Let us assume that all of these subclasses share operations O1, O2, O3, and O4, but operation O5 is shared by A1 and A2 and is somewhat different for A3. Let's call this different operation O5.1. What do the class hierarchy and the inheritance look like?

If we pick a structure like that shown in the first example in 2, we store O5 in two different classes. That's bad because of the dual maintenance: every time we make a change in the operation, we have to make the change for both class A1 and class A2. The hierarchy in the second example in 2 solves this problem, but it introduces a new class, A0, thus making the hierarchy more complicated. The best solution is represented in the third example in 2, where O5 appears in two places (class A and class A3). Operation O5 in A3 is really O5.1 and it acts like a redefinition of operation O5 in A; or, to use a more familiar AS/400 term, it overrides operation O5 in A.

If we pick a structure like that shown in the first example in Figure 2, we store O5 in two different classes. That's bad because of the dual maintenance: every time we make a change in the operation, we have to make the change for both class A1 and class A2. The hierarchy in the second example in Figure 2 solves this problem, but it introduces a new class, A0, thus making the hierarchy more complicated. The best solution is represented in the third example in Figure 2, where O5 appears in two places (class A and class A3). Operation O5 in A3 is really O5.1 and it acts like a redefinition of operation O5 in A; or, to use a more familiar AS/400 term, it overrides operation O5 in A.

When operation O5 is requested for an object in class A3, the version in class A3 will be invoked. When it is requested for an object in class A1 or A2, the version in class A will be invoked. The duplication of O5 is not harmful, since the operations are different in substance even though they have the same name. This mechanism is known as redefinition of an operation.

Consider the same classes and operations shared differently: A1 has all the operations except O1 (i.e., it has O2, O3, O4, and O5); A2 has all the operations except O2; and A3 has all the operations except O3. The first example in 3 shows a class hierarchy that accurately represents the above situation, but it has a drawback: it requires duplication of code (O1, O2, and O3 are each stored twice). This problem can be solved by the mechanism known as exclusion, which allows a subclass to exclude certain operations of its superclasses from inheritance.

Consider the same classes and operations shared differently: A1 has all the operations except O1 (i.e., it has O2, O3, O4, and O5); A2 has all the operations except O2; and A3 has all the operations except O3. The first example in Figure 3 shows a class hierarchy that accurately represents the above situation, but it has a drawback: it requires duplication of code (O1, O2, and O3 are each stored twice). This problem can be solved by the mechanism known as exclusion, which allows a subclass to exclude certain operations of its superclasses from inheritance.

This mechanism is represented in the second example in 3. It works a little bit like this: I'd like to inherit the house of a rich aunt, but I want nothing to do with her 43 cats. Maybe she can leave those to my sister!

This mechanism is represented in the second example in Figure 3. It works a little bit like this: I'd like to inherit the house of a rich aunt, but I want nothing to do with her 43 cats. Maybe she can leave those to my sister!

Polymorphism

Last, but not least, one more OO concept: polymorphism. It derives from two Greek words, poly, which means "many," and morphos, which means "shape" or "form." In order to understand this concept, let's look at a simple thing like the plus sign (+). We use it to instruct the computer to add numbers, as in 12 + 32 or 3.14 + 7.5. If you know anything about computer arithmetic, however, you are aware that those two simple additions cause the execution of very different machine code, because the first is the addition of two integers and the second is the addition of two decimal numbers. In other words, + has (at least) two meanings, and we leave it to the compiler, or maybe even the run-time environment, to figure out which machine code needs to be executed. This process is called operator overload. Polymorphism is the overload of an operation. It simply means sending the same message to any number of objects and letting them sort out which operation needs to be invoked.

Although the polymorphism mechanism is somewhat similar to the redefinition mechanism, polymorphism is more like multiple definition because there is no inheritance relationship between the different versions of the operation. A redefinition defines a precedence order along a branch of the hierarchy of classes, while polymorphism defines a set of variations of the same operation belonging to various classes, not necessarily related.

In real life, a good example of polymorphism is an orchestra. All musicians receive the same messages?the score and the signals from the conductor?yet every one of them acts upon these requests differently, as the technique for each specific instrument demands.

In the AS/400 world, a good example would be DSPFD. This request can be sent to any kind of file (DSPF, SAVF, ICFF), but the DSPFD operation invoked is different for each of those file types. The alternatives to polymorphism would be this:

1. Have distinct commands and interfaces (DSPDSPFD, DSPSAVFD, DSPICFFD). This would mean that we have to remember more commands, and, what's worse, it implies that we must know up front what kind of file we are dealing with. A segment of code to display the description of all the files in a list will have to include if-then-else logic to select which command to invoke.

2. Have a single DSPFD operation in the class File. Again, this operation would have to have selection code to decide which code to execute.

Selection code is very inconvenient because it needs to be modified every time a new kind of file is added. The polymorphic implementation will have distinct operations for each file type, but all these operations will have the same name (e.g., a DSPFD operation in class DSPF, a DSPFD operation in class SAVF). When the object receives the request to execute the DSPFD operation, it goes to its own class and therefore invokes the correct operation for its type. The selection is made by sending the request to a specific object rather than by if-then-else selection code.

What Is an OO Application?

Now that we have all the concepts clearly understood, we have to look at how all the pieces of the puzzle fit together.

The objective of any application, OO or otherwise, is to process some data. In an OO application, data resides in the object instances, so it follows that only operations can change that data. In other words, running the application must mean executing a certain set of operations. This raises a legitimate question: in what way is this different from the good old way of calling a set of programs in some predefined order?

An OO application is initiated by some kind of external request, much like its procedural kin. This request may be a system command, a menu selection, or a button click. The initial operation will cause two things to happen:

1. The data of the target object instance is changed. If the change is significant, we call that change an event, and we say that the object changed state (i.e., the object instance is different in some significant way). For example, the application starts by invoking an operation to mark a certain invoice as paid. An instance of the object?in this case, Invoice?changes some field in its data structure to a predefined value that indicates payment was made.

2. As a result of this change, one or more new operations may be invoked by way of sending requests (or messages) to the objects those operations will apply to.

This may cause an event, which in turn may cause invocation of other operations. For example, as a result of the invoice having been paid, the customer record must be updated to reflect the balance owing; in OO terms, an instance of the object Customer, likely identified by a customer number field in the Invoice object, must be changed by invocation of a specific customer operation, namely UPDATE_BALANCE.

This process is not unlike ordering a hamburger! As soon as your order is taken, the employees go about their predefined tasks: one will flip your burger, one will get the fries, and someone will put it together. Some of these steps will be executed in sequence, while some will be done in parallel. The timing of each action may be different from order to order, even if what two people ordered is the same menu item (say, the fries are not quite golden yet when the second order arrives, so you will have to wait a bit longer). This is the first fundamental difference between procedural and OO applications.

The second key difference is in the total independence of the operations. Operations are said to be isolated from cause and effect. What this means is that an operation acts like a well-trained spy: it has no idea who asked it to do its thing or why, nor what the consequences of doing its thing will be. That's because operations are not invoked by other operations (that would be no different from a procedural call); rather, the request (or message) management system "notices" events and invokes operations accordingly. This is called event-driven programming (EDP).

How Does the AS/400 Measure Up?

The architecture of the AS/400 is OO. All the OO concepts are supported and used in the system. The key point is that, until recently, all of this was supported only internally. That is, you could not create your own object types (classes). This is changing very rapidly. VisualAge C++ for OS/400 brings to the AS/400 the power of objects and class libraries, which you enjoy on your PC. As standards such as System Object Model (SOM) and Distributed System Object Model (DSOM) become available, more and more of the AS/400 products will be enabled to these standards, thus allowing the creation, use, and manipulation of objects on this platform.

Today, we build applications out of high-level programming language statements. This is an inherently difficult, slow, and inefficient process because the "building blocks" are so small and because, most of the time, we start from scratch. While good modularization, external file descriptions, and copybooks can increase somewhat the reuse element in your application, we are seldom able to truly reuse such pieces of code without first modifying them.

In this new world of OOT, applications will be built out of collections of classes (i.e., objects with their predefined operations) with a visual tool that is capable of browsing large collections of classes, selecting the right ones for your needs and connecting them as appropriate.

How Will OOT Affect You?

Like any other technology, this one raises the all-important question, "How is this going to change my life?" First, here is what is not going to change: we'll still have two kinds of programmers?end-user programmers and people like me. I write compilers, utilities, and system software. I worry about stacks and queues and parsers and lexical analysis and hashing and a lot of other stuff that likely won't mean a thing to you if you make your living by writing end-user applications. In other words, people like me provide the tools used by the end-user programmer to put together applications. In the future, those tools will be class libraries and programs to store, browse, and assemble objects.

If you want to be the provider of class libraries in some specific business domain, you will need to understand OO concepts in minute detail, and you will likely use Smalltalk or C++ as your main language. OO analysis and design techniques will be your bread and butter.

On the other hand, if you are an end-user programmer, you will be putting together domain applications using existing class libraries. Your focus will be using visual tools for assembling parts and library browsers for finding the right parts. It is not an exaggeration to say that most of your time will be spent shopping for parts. I know I have a nut for every bolt in my toolbox, if I could only find them!

Frameworks are kits of parts designed to work together and deliver a plain vanilla version of an application. Depending on your needs and skills, you can go on to customize the application, either with special parts or by changing a few of the existing ones to suit your needs. This process is very similar to using an Erector Set, a box of parts that your child can use to build a given set of toys.

Preparing for Tomorrow

Assuming that I have convinced you that the future is in the world of objects, how do we get there from here? Many people will argue for the cold turkey approach, meaning that you will have to abandon everything you have done so far and start with a blank sheet of paper, a whole new investment in technology, and the best hopes.

Frankly, I don't think that such an approach is either realistic or likely to be successful. Very seldom, if ever, can a new technology replace an old one without some substantial period of coexistence. And when it comes to software, the amount of legacy code is so huge that its very existence means it will have to function together with the new applications for some time to come. What that means is simply that OOT will have to build a bridge that allows this coexistence. In other words, code written in the traditional 3GLs will have to interact with objects.

Introducing new technology is perhaps a discipline in itself, or at least a substantial part of the art (or is it science?) of management. Getting into a lot of detail on this subject is beyond the scope of this article. In my opinion, these are the key points:

1. If you can, start small.

2. Choose a tool that best suits your needs, and try it out on a small project.

3. Seed your team with some OO expertise, preferably coming from a person who is well-known and highly regarded by the team, at least from a technical point of view.

However, if you cannot afford or simply do not want to start on this path right now, there are some things you can do to prepare for this new technology:

1. Think modular. In ILE, it is a lot easier to structure your application in a modular way, using bound calls and service programs.

2. Pay a lot more attention to the specification of each module. Make it as accurate and as clear as possible. Try to enforce the interface and specification as much as possible.

3. Try out some visual tools and event-driven programming. One good (and some say fun) way of doing so is by adding some fancy graphical user interfaces (GUIs) to your applications.

You will find that, once these new habits have taken hold, moving on to OOT will be somewhat simpler. No matter what you do, however, going to OOT is a substantial change. And change is painful. People do resist change, at least for a while. Change does cost money and effort. If anyone tells you that you are going to see an immediate cost reduction, he's crazy! Down the road, though, the savings will be substantial. Can you imagine a software company today building all of its software in machine language and still competing with the users of 4GLs and CASE tools? If anything, the productivity difference between OOT and current technologies will be even larger.

What about such arguments as these? Performance will be unacceptably low! The programs will be just too big! This will never work! The results will never justify the costs! Well, to those of us who were around when we moved from assembler to HLL, those arguments sound rather familiar!

The world is heading the way of objects! Are you on your way or in the way? The key is to at least get started in that direction.

A future article will explore the fundamentals of OO analysis and design. How will we have to change our thinking in these very important phases of software development if the objective is an OO application? How do we select the objects? How do we find the right class hierarchy? How do we determine what operation will be needed? What does "event-driven" really mean? Some answers will be provided in the next installment of "The Nature of Objects."

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

The Nature of Objects in Applications

Figure 1: AS/400 Class Hierarchy

The Nature of Objects in Applications

Figure 2: Shared Inheritance

The Nature of Objects in Applications

Figure 3: Shared Inheritance and Exclusions