Part 1: Object Oriented Programming

By John Kozacik


 * Component Programming and Digitalk's PARTS
 * Part 1 - Object Oriented Programming

Introduction
Cincinnati Team OS/2 recently received an examination copy of Digitalk's PARTS, and I was granted the job of reviewing this product. Because this software is one of a family of truly leading-edge application development tools, It would be very difficult to do it justice in a single article. Additionally, this product is part of a new paradigm in how programming is thought about and how solutions to problems are conceptualized. Therefore, I will devote several articles to this product in an attempt to explain the technical foundation that supports this product and the context in which this product finds its best utilization, as well as an examination of the product itself.

Background
Process Orientation. The dominant and seemingly natural way that one thinks of computer programs is in terms of the processes that are involved. When you bake a cake or change the oil in your car you think in terms of the sequence of operations you will perform to get the job done rather than in terms of the items you will use. One does this primarily because the nature of the items involved are obvious. You know what flour looks like and that when you add milk to it it will change its consistency, or that, when you open a can of oil and tilt it its contents will pour out. Hence, when you sit down to write a set of instructions, you organize the steps involved in what you want to do in their proper sequence. But imagine that you were given a set of instructions to do thoracic surgery or assemble a Wankle engine. Neither the tools you would be using nor items that you would be working on would be familiar. So the first order of business would most probably be to figure out what the pieces you had to work with did, what would they do when you tried to manipulate them, and what were their relationships to one another. Now step back from your programming tasks a bit and look at them. What are you working with? Records in a flat file, structures of dissimilar data, flags to keep track of whether something has happened or not? There is nothing to tell you when you've moved to a certain column of a record that the data you're working with is zoned and not packed, that the field is really as long as you think it is, or that the record you're working with is the correct one in the sequence that the rest of the process is supposed to be indexing through in its buffer. In this context it would be just as easy to mistakenly try to crack a stick of butter against the side of a mixing bowl and empty its contents into your recipe rather than performing the same operation with an egg, as it would be to update the wrong record in your program. The key here is that procedural programming gives you no help when it comes to performing the correct operation on the correct item. In our real world we don't (usually) perform such mistakes because it's obvious what we are supposed to do with the things we're working with.

Object Orientation: a view
Computer Science is a misnomer: computer science is not a science. There are no fundamental principles which we can use to ensure that our programs will be correct, or even efficient. The very best of us are simply good at finding efficient and understandable ways of combining language features into a design that solves a particular problem. The deep thinkers in our field have come up with the common-sense solution that it would be very beneficial if the programming process focused first on defining the items we are working with and then describing what we will do with them. This approach accepts the fact that the fields in records and structures are not naturally obvious things such as pipe wrenches and egg beaters, and that, before we start doing any operations, we had best define very thoroughly what the things we are working with are and what we are allowed to do to them. This is the essence of object oriented technology.

Encapsulation
The realization of this philosophy (object orientation) has taken the form of a number of different languages. Each of these languages creates consistent rules for defining the items that will be worked with and how they will behave, and to allow ways of getting each item to act properly. From these attempts, several general properties have developed which characterize these types of languages as object oriented. One is encapsulation. This means that what an item is is not shared outside of itself: it has distinct boundaries just like a physical object. The things which make up a feather duster constitute the feather duster: it is composed of a wooden handle and feathers, flexible parts with a large surface area to collect and hold dust. The wood and the feathers and the physical arrangement and size are all contained within the thing we recognize as a feather duster. We use an item via its interface: the handle of the feather duster is for holding and its feathers are for brushing against dusty surfaces. We do not disturb the structure of the wood in the handle or the glue that holds the feathers to the handle when we use it. A programming object has encapsulated parts which are not interfaced with such as internal flags or accumulators that constitute that object. A data object has an interface, which are the functions we use to operate it. This is known as the public part of the object. It is what the object exposes for the programmer to work with just as the handle of the feather duster is what we grasp in order to use it.

Class and Inheritance
In our own real environment we can recognize many types of objects; chairs, for instance. We easily recognize a chair as being a chair by its legs, seat, back, and arms if it has them. Once we have created such an archetypal object, we can visualize variations of that type of object easily. If that object is the plans to build a chair, we can copy and modify those plans to create different kinds of chairs. Object oriented languages mirror this categorization of objects in our real world through the concept of class and mirror the creation of new objects in our real world through the property of inheritance. Inheritance is the means by which an object oriented language allows the construction of child objects, once the parent class has been defined. Inheritance is considered the distinguishing characteristic of object oriented languages, and contributes greatly to the value of object oriented languages in aiding the construction of programs. And, by this property, programming is moved from considering what one will do to defining what one will work with.

There is a functional difference between the archetype, the concept or plan of the fundamental features of what constitutes a chair, and an actual chair. In object oriented languages this difference is described in terms of class and instance. The class is the archetype or plan that defines what a chair consists of.

The actual physical chair, the thing someone sits on, is an instance of the class.

Polymorphism
Finally, a chair can be used for things other than serving as a resting place for a person. One could stack books on a chair and thus use it as kind of a shelf. One could stand on a chair to reach the top of a bookshelf thus using the chair as a ladder. This same kind of object usage is defined in an object oriented language as polymorphism. You employ polymorphism in any ordinary program when you use the plus operator to add two numbers. Sometimes the numbers are integers, sometimes the numbers are floating point, and sometimes the numbers are a mixture of different precision's or a combination of integer and floating point types. In all cases the same operator is used to operate on different types of data. The plus operator is polymorphic in the kinds of data types it operates on. Polymorphism in an object oriented language is the ability of an object to refer to instances of different classes.

Messaging
The messaging operation is a result of encapsulating an object's behavior. Once an object class has been defined and an instance of that object created, the object can be used in a program. The sort of things it is possible to use a particular object for are coded in the definition of the object as its behavior; these are functions that are part of the object and that operate on data to which the object has access. They are invoked by the program sending a message to the object. The messages that a program can send to an object are those functions that are public and represent the interface that the object presents to the program. For example, an object may contain data and routines to both format and print that data. A program would cause the printing of such an object's data by sending a message to the object that would invoke the object's print routine. The interface the program would use would be the print message, while the routine for formatting the data would probably be hidden to the program, since the knowledge about how to format its own data would most reasonably reside within the object. The program could not get an object to perform any function that was not part of the object. This prevents inappropriate behavior of an object and by association, the program the object is a part of.

Benefits of Object Oriented Programming
There are very substantial benefits to focusing attention on objects and behaviors rather than processes. Unfortunately, the benefits come under the heading of 'delayed gratification'. Said another way, it makes sense to learn and use object oriented languages now so that our lives will be easier in the future.

A side-effect benefit of object orientation is that it moves the focus of effort toward the front end of the project. All of the methodologies and all of the application development tools available today have one thing in common: they force the developer to spend more time defining what he or she is going to do. The end result of such effort is that the end product, be it a program or a system, will be closer to what the end-user needs. The advantage of spending a large amount of time in doing this is that the end product will be less likely to need reworking once it is assembled. Since it is known that reworking a finished system takes 10 to 15 times the amount of effort required by the project initially, such strategies can pay off handsomely.

Another benefit of object oriented programming is that it facilitates communication between the people involved in the project. In procedure oriented systems, when an Analyst and end-user talk, their focus is the problem to be solved. When the system architect and programmers talk, their focus is the solution to the problem. These two perspectives do not include a lot of common ground between the two groups. If the project is object oriented, the objects that the architect and programmers are working with are the same objects that the analyst helps the end-user to identify. This facilitates communications tremendously and results in an end product that much more closely agrees with what the end-user needs to accomplish his or her ends (and the end-user's needs are, after all, the reason we have jobs).

Anyone who has written a large program finds it startling to see how obscure its workings become after several months absence in dealing with the code. Object orientation reduces this loss of intelligibility greatly by its definition of the programming objects and their behavior. Two types of changes will be made to a program during maintenance: either the nature of the object will be changed, or the sequence of processing will be changed. Because of inheritance, the addition of data or the change to a function of an class will be replicated to include every instance of an object in the inheritance path throughout the program or system. One does not have to find every occurrence of the code which needs to be modified in the system and ensure that identical changes are made in each case. Conversely, the significance of an operation on an object is much more obvious when all of the data and processes are encapsulated within a single reference to the object. Because of this, maintenance of object oriented code is much simpler than maintenance of procedural code.

Once an object has been defined, what that object consists of, its data and behavior, can be published for reference by other persons involved in the business process. Since the object must represent something that is intelligible to the user as well as the programmer, the usefulness of defining an object is shared not only by the people involved with computer technology, but by the clients who are paying for the technology.

Summary
Object oriented programming follows a very natural way of looking at the programming process, but is fundamentally different from the procedural orientation most of us have grown up with. Object oriented programming also requires us to pay very careful attention to the construction of things we will work with in order to provide the benefit that the procedures we perform will make sense. The properties of inheritance, encapsulation and polymorphism are key to object oriented programming and together identify such a language uniquely. Object oriented programming has nothing directly to do with creating graphical interfaces, but rather aids the process of creating such interfaces greatly. The next article will talk about Graphical User Interfaces (GUI's) and event-based programming. The concepts involved in object oriented programming and event based programming will together form the base for understanding how Digitalk's PARTS works and why it is important.

''© Copyright 1994 by John J. Kozacik, Inc., All rights reserved. No portion of this article may be reproduced except as follows: Permission to reprint this article is granted to non-profit organizations for non-commercial use provided credit is given to the author and John J. Kozacik, Inc. is provided one copy of the publication containing the reprinted article.''