"Since its inception, and more so lately, the adjective object-oriented has been bandied about with carefree abandon with much the same reverence accorded motherhood, apple pie and structured programming."

-- from [Bhaskar, 1983], page 8

"What is object-oriented programming? My guess is that object-oriented programming will be in the 1980's what structured programming was in the 1970's. Everyone will be in favor of it. Every manufacturer will promote his products as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is."

-- from [Rentsch, 1982], page 51

PROLOGUE

In 1982, some of my clients began asking me to explain something called "object-oriented design." Although I had heard the term myself, I must admit that, at the time, I knew very little about it. Being a scientist by training (undergraduate: chemistry, graduate: chemical physics), I had a plan of attack:

1. Begin a literature search, with the following goals:

a. Find the earliest documented mention of the term (i.e., "object-oriented)

b. Realizing that the term was technological in origin, follow the discussion (in books, articles, etc.) with the intention of:

i. discovering different facets of the technology. I have learned from experience that no one author, no matter how gifted, knows all things about, or expresses complete knowledge of, a given topic. Quite frankly, you have to read "a large pile of references" before you can begin to claim that you know something useful about a subject.

ii. noticing the emergence of new facets of the technology. Most, if not all, technologies are in a constant state of flux. One aspect of this is the continual introduction of new concepts and terms.

iii. following concepts as they mutated. In any living technology, concepts and terms take on different meanings and connotations with time. Some of these changes are subtle, others are drastic. Sometimes entire sets of ideas disappear. Only if a technology exists for a prolonged period of time, do some definitions become, for all intents and purposes, "frozen." In the early stages of a technology, the mutations are often frequent and violent.

iv. identifying alternative, and possibly, conflicting, interpretations of the same concept or term. Each of us "sees things in a different light." "Scientific debate" is hardly an original concept.

v. increasing my chances of being able to separate "concepts" from "implementations." The job of scientists, mathematicians, and engineers is to identify valid patterns, i.e., abstractions. Low levels of abstraction tend to be implementations, while higher levels of abstraction tend to be concepts. Concepts, I have found, tend to be more more "mobile" than are implementations, i.e., they can be used in more situations. (Does the word "reuse" come to mind? ;-))

c. Being able to "back up" (justify) any conclusions or recommendations I might make to my clients. I might really have an occasional good idea, but my clients felt better if, for example, they knew they were not going to be the first ones to try it out.

2. Become comfortable enough with the technology to:

a. explain it to all levels of personnel, e.g., from corporate management to the most technical of the techies,

b. create and deliver organized, coherent courses and seminars on the technology -- complete with very detailed "how to do it" and "how to know that you did it correctly" presentations.

c. make specific recommendations as to how the technology could best be applied to any specific project my clients had in mind. [Notice that this implies more than just concepts. Application of technology seldom takes place in a vacuum. My clients needed commercial information (e.g., who sells the best tools?) infrastructure information (e.g., how is this going to impact our internal organization , policies, and procedures?), and political information (e.g., how is this going to impact our dealings with our customers?).]

My goal was _not_ to invent any new technology. Indeed, I am a firm believer, that anything I can think of has probably been thought of, and documented, by many others before me. My main purpose was, and still is, to make the technology real, i.e., to get it off of paper, and into practice.

All along, my clients kept asking me questions like: "Are we the only ones doing this?", "Is this stuff going to go away?", and "Is IBM interested in object-oriented technology? It ain't real until IBM 'gives it its blessing.'" I kept assuring them that interest in things object-oriented was growing.

Well, sometime around 1985-1986, "the stuff hit the fan." "All of a sudden," object-oriented technology was an "overnight sensation." I began to feel better. However, my relief was short lived.

I noticed that "object-oriented " was being referred to as "the latest fad." People were claiming that object-oriented was just a buzzword, or old ideas in new clothing. Worse, in addition to "everybody trying to get on the bandwagon," there were growing numbers of "rabid object-oriented zealots" who were more than happy to spread "object-oriented hype" like an oil slick over the software engineering landscape.

[But, then again: "Zealotry is the cutting edge of change." (I heard this on NPR -- National Public Radio.)]

I would like to say that I have never seen anything like this before, but that wouldn't be true. ("It's deja vu all over again." -- Yogi Berra) I have run into this problem with such items as: structured programming, relational databases, and life-cycle methodologies in general. Each time a "new" technology becomes popular, people claim it has no definition.

Let's see if we can get a handle on this "object-oriented thing."

BRIEF HISTORY OF OBJECT-ORIENTED TECHNOLOGY

If you really dig deep, you will find a number of object-oriented concepts in the early (late 1940s, early 1950s) work in artificial intelligence. Concepts like "objects" and "attributes of objects" were indeed mentioned. However, the most significant contributions to object-oriented technology from the AI community have been much more recent.

The next significant "blip" to show up is Sutherland's Sketchpad ([Sutherland, 1963]). This is probably the first significant reference to "object-oriented graphics."

Many object-oriented enthusiasts like to cite the introduction of Simula ([Dahl and Nygaard, 1966]), as the first (or at least an immediate precursor to) object-oriented programming language. Kristen Nygaard and Ole-Johan Dahl introduced a number of object-oriented concepts in Simula, e.g., encapsulation at a higher lexical level than mere subprograms, and the "virtual" concept (i.e., localizing state information and operations for an object within the object itself).

[In [Wexelblat, 1981], Dahl relates an amusing story about a new grad student at the University of Norway. The student rushed into the office of the computer science department, and informed the department head that two men were arguing very loudly and forcefully in the building, and that the grad student was afraid the discussion would quickly become violent. The department head went into the hall and listened. He then returned and assured the grad student that there was no problem -- it was just Nygaard and Dahl discussing Simula.]

Also during the late 1960s, Alan Kay was working at the University of Utah on FLEX. Kay wanted FLEX to be "the first personal computer to directly support a graphics and simulation-oriented language." (See [Kay, 1977].) Kay wanted the computer to be designed so that it could be used by non-expert computer users. He later said that, during the FLEX effort, he had been guided "by the central ideas of the programming language Simula ... ."

It is important to realize that Kay viewed object-oriented techniques as a means of _simplifying_ computer usage. When you hear people say things like, "object-oriented systems more closely resemble 'real life' than do, for example, functional decomposition systems," they are echoing Kay's original intentions.

Unfortunately, Kay was frustrated by the hardware and software limitations in the late 1960s, and "although the design of FLEX was encouraging, it was not comprehensive enough to be useful to a wide variety of nonexpert users."

Around 1970, Kay went to work for Xerox at the Palo Alto Research Center (PARC). At Xerox PARC, he helped to create a hardware/software system called "Dynabook." The hardware part of Dynabook later became the Xerox STAR. The software part of Dynabook was what we call Smalltalk. The first version of Smalltalk was released in 1972.

It was also around 1970, that the term "object-oriented" came into significant use. Some people credit Alan Kay as the first to use the term. He used it to describe the thinking behind Smalltalk, and many people think of Smalltalk as the first and archetypical object-oriented programming language. (See [Goldberg and Robson, 1983].)

It was not until the early to mid 1980s that we began to see a proliferation of so-called object-oriented programming languages, e.g., Objective-C ([Cox, 1986]), C++ ([Stroustrup, 1986]), Self ([Unger and Smith, 1987]), Eiffel ([Meyer, 1987]), Flavors ([Moon, 1986]), and Trellis/Owl ([Schaffert et al, 1986]).

[If you do any extensive reading on "object-oriented programming languages," you will find a significant amount of variation. For brevity, I will skip a series of discussions on, for example, class-based vs. "classless" object-oriented languages, the importance of physical (i.e., syntactical and semantic) encapsulation, and dynamic vs. static binding.]

The late 1970s also saw the introduction of object-oriented computer hardware. Although some claim that the IBM System 38 was an object-oriented architecture, it is really more of a "capability-based" architecture. (See, e.g., [Fabry, 1974], [Levy, 1984], and [Myers, 1982].) Hardware architectures that are much more in keeping with the object-oriented spirit include the Intel iAPX 432 ([Intel, 1980] and [Organick, 1983]) and Rekursiv ([Pountain, 1988]).

Object-oriented database management systems (OODBMSs) which were virtually non-existent in 1980, seem to be growing in strength. References on the topic abound, e.g., [Dittrich and Dayal, 1986] and a new book by Stanley B. Zdonik (published by Morgan Kaufmann).

Unfortunately, one area which is badly in need of expansion is "truly object-oriented computer aided software engineering tools" (OO CASE). As of early 1989, virtually none existed. The good news is that many sources predict that within the next 2 years, there will be explosive growth in this area.

To sum up: Object-oriented technology got going in the late 1960s, began to take on significant definition in the 1970s, and exploded during the mid-1980s.

O.K., SO WHAT IS "OBJECT-ORIENTED PROGRAMMING"

A flippant (and fairly inaccurate) answer to the question, "what is object-oriented programming?", would be: developing an application using an object-oriented programming language. What most of us want, however, is an answer that extracts the essence of the concept.

Peter Wegner ([Wegner, 1986]) give us the beginnings of an answer:

"We define 'object-oriented' so that it includes prototypical object-oriented languages like Smalltalk and Loops, but excludes languages like Ada, Modula, and Clu which have data abstractions but are not generally considered object-oriented. Support of data abstraction is a necessary but not sufficient condition for a language to be object-oriented. Object-oriented languages must additionally support both the management of collections of data abstractions by requiring data abstractions to have a type, and the composition of abstract data types through an inheritance mechanism:

Very often, definitions of "object-oriented anything" come off as definitions of the way Smalltalk does it. What I think is missing is the original intentions of Alan Kay. Kay wanted object-oriented to be simpler than conventional programming, and more like "real life."

Let's start with some basics. First, think of "objects" as you do in everyday (non-software-related) life. For example, if you knew nothing about computers, you would still have no problems identifying a a car, a bank account, or a human being as an object. If asked, you probably would acknowledge that none of these items is only data, or only functions. You might even admit that these items are all "black boxes" in the sense that they each present an interface to those who come into contact with them, and they all restrict access to their internals.

This is probably one of the most important points about object-oriented approaches, i.e., objects are black boxes. One of the reasons that electronics engineers seem to be so much more productive than their software counterparts is that they respect and understand the value of black boxes. For example, you seldom see an engineer scrapping the plastic off the top of a chip. (Yes, I know it's really a dual in-line package (dip).)

For the next concept, let's consider the implementation of a stack in a number of different programming languages. For purposes of our discussion, we will consider a stack to be a list to which we may add or delete items from one end only, i.e., a stack is a last in, first out (lifo) structure. Now let's ask some programmers haw they might implement a stack:

- A Fortran programmer might choose to implement the stack as an array.

- A C or Pascal programmer might implement the stack as a linked list.

- Someone with an Ada or Modula background might realize that a stack is more than just data. For example, there are rules which govern how this data must be handled. They might choose to implement the stack as a package (Ada) or a module (Modula).

At this point, we have stumbled on two more aspects of objects:

1. Objects are _complete_ entities. They are not "just data" or "just functions," or even "just data and functions combined." Using the capabilities of our programming language we must strive to capture the most complete abstraction possible. If our language provides exceptions and constants, for example, then we may wish to incorporate these items into our programming language abstraction of the "real world" object.

2. Objects are encapsulated concepts. If our programming language provides encapsulating mechanisms (e.g., Ada's packages, Modula's modules, Simula's classes, and Smalltalk's classes), we would be strongly advised to use these mechanisms. Of our programming language lacks these mechanisms, then we will have to settle for conceptual (i.e., not physical) encapsulation.

Note that encapsulation mechanisms allow you to both hide the underlying implementation, and present a controlled interface to the outside world.

What about those other things that Wegner mentioned? Let's look at "data abstraction" first. Abstraction is the process of of focusing on the essential details while ignoring the inessential details. In functional abstraction, we may know a good deal about the interface information, but very little about how an actual function is accomplished, i.e., the function is a "high level concept" (an abstraction).

Data abstraction is implemented "on top of" functional abstraction. In data abstraction, not only is the function performed an abstraction, but the interface data is also treated as an abstraction. For example, consider a generic sort utility. The sorting algorithm may be unknown (functional abstraction), but the items to be sorted are also treated as an abstraction.

What we really should be talking about is not "data abstraction," but rather "object abstraction." For example consider a list object. If the same list object can be used for "a list of names," "a list of addresses," or "a list of stacks," then we can treat the objects which might be placed in the list as an abstraction.

Notice, once again, that real life is creeping back into the picture. In everyday life, we have few problems separating the concept of a list from those items which may be placed in the list.

What about inheritance? If I were to tell you that I had a "Frample" in the parking lot, I might get a more than one puzzleed look. If I then told you that "a Frample is an automobile," some of the puzzlement would go away. You might suspect that a Frample had four wheels, was design to carry people and other items from one location to another, and had an engine. This is an example of inheritance.

Inheritance means simply that a category of objects (sometimes referred to as a "class") acquires characteristics from another category of objects (i.e., its superclass). [A variation on this scheme is "delegation" where one object acquires characteristics from another object -- but that's another story.]

In languages which closely follow the Smalltalk model, inheritance is a dynamic concept, but there are other schemes, e.g., static mechanisms like layers of abstraction. Each scheme has its strong and weak points.

LOCALIZATION

Localization is the process of placing items in close physical proximity to each other. It is the concept of localization which most clearly shows the differences between object-oriented and other forms of programming:

- functional approaches localize information around functions

- data-driven approaches localize information around data

- object-oriented approaches localize information around objects.

Without even completely understanding the concept of just what an object is, but recognizing that objects are not functions, and that objects are not data, we can see that there will be a difference in how the software is arranged.

SUMMARY

To summarize, object-oriented programming requires that:

- information be localized around objects (i.e., not around functions, and not around data) [Remember: An object is a specific thing or characteristic. Objects are black boxes, i.e., their internal implementations are hidden from the outside, and all interactions with an object take place through a well-defined interface.]

- objects must be complete entities, i.e., using the facilities of our programming language, we must create as complete an abstraction of the "real world" (conceptual or physical) object as possible.

- objects must be highly independent of each other, but must be provided with some mechanism for interaction.

Would you look at the time? Its late again. This message is even bigger than the last one. Thanks for listening.