eberard@ajpo.sei.cmu.edu (Edward Berard) (10/29/89)
"When I use a word," Humpty Dumpty said, in a rather scornful
tone, "it means just what I choose it to mean -- neither more
nor less."
"The question is," said Alice, "whether you can make words
mean so many different things."
-- from Alice's Adventures in Wonderland [1865] by
Lewis Carroll (Charles Lutwidge Dodgson)
"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 <fill in the blank>" 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:
"object-oriented = data abstraction + abstract data types +
type inheritance."
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.
-- Ed Berard
Berard Software Engineering, Inc.
18620 Mateney Road
Germantown, Maryland 20874
Phone: (301) 353-9652
FAX: (301) 353-9272
P.S.: I will get to OOD and OORA in the next message.
BIBLIOGRAPHY
[Bhaskar, 1983]. K.S. Bhaskar, "How Object-Oriented Is Your System,"
SIGPLAN Notices, Vol. 18, No. 10, October 1983, pp. 8 - 11.
[Bobrow et al, 1988]. D.G. Bobrow, L.G. DeMichiel, R.P. Gabriel, S.E.
Keene, G. Kiczales, and D.A. Moon, "Common LISP Object System
Specification X3J13 Document 88-002R," SIGPLAN Notices, Vol. 23,
Special Issue, September 1988.
[Booch, 1986]. G. Booch, Software Engineering with Ada, Second
Edition, Benjamin/Cummings, Menlo Park, California, 1986.
[Cox, 1986]. B.J. Cox, Object Oriented Programming: An Evolutionary
Approach, Addison-Wesley, Reading, Massachusetts, 1986.
[Dittrich and Dayal, 1986]. K. Dittrich and U. Dayal, Editors,
Proceedings of the 1986 International Workshop on Object-Oriented
Database Systems, IEEE Catalog Number 86TH0161-0, IEEE Computer
Society Press, Washington, D.C., 1986.
[Dahl and Nygaard, 1966]. O.J. Dahl and K. Nygaard, "SIMULA -- an
ALGOL-Based Simulation Language," Communications of the ACM, Vol. 9,
No. 9, September 1966, pp. 671 - 678.
[Fabry, 1974]. R.S. Fabry, "Capability Based Addressing,"
Communications of the ACM, Vol. 17, No. 7, July 1974, pp. 403 - 412.
[Goldberg and Robson, 1983]. A. Goldberg and D. Robson, Smalltalk-80:
The Language and Its Implementation, Addison-Wesley, Reading,
Massachusetts, 1983.
[Intel, 1980]. Intel Corporation, iAPX 432 Object Primer, Manual
171858-001 Rev. B, Aloha, Oregon, 1980.
[Kay, 1977]. A.C. Kay, "Microelectronics and the Personal Computer,"
Scientific American, Vol. 237, No. 3, September 1977, pp. 230 - 244.
[Levy, 1984]. H. Levy, Capability-Based Computer Systems, Digital
Press, Bedford, Massachusetts, 1984.
[Moon, 1986]. D.A. Moon, "Object-Oriented Programming With Flavors,"
OOPSLA Conference Proceedings, (Special Issue of SIGPLAN Notices, Vol.
21, No. 11, November 1986), Association for Computing Machinery, New
York, New York, 1986, pp. 1 - 8.
[Meyer, 1987]. B. Meyer, "Eiffel: Programming for Reusability and
Extendability," SIGPLAN Notices, Vol. 22, No. 2, February 1987, pp. 85
- 94.
[Myers, 1982]. G.J. Myers, Advances in Computer Architecture, Second
Edition, John Wiley & Sons, New York, New York, 1982.
[Organick, 1983]. E. Organick, A Programmer's View of the Intel 432
System, McGraw-Hill, New York, New York,1983.
[Pountain, 1988]. D. Pountain, "Rekursiv: An Object-Oriented CPU,"
Byte, Vol. 13, No. 11, November 1988, pp. 341 - 349.
[Rentsch, 1982]. T. Rentsch, "Object Oriented Programming," SIGPLAN
Notices, Vol. 17, No. 9, September 1982, pp. 51 - 57.
[Schaffert et al, 1986]. C. Schaffert, T. Cooper, B. Bullis, M.
Killian, and C. Wilpolt, "An Introduction to Trellis/Owl," OOPSLA '86
Conference Proceedings, Special Issue of SIGPLAN Notices, Vol. 21, No.
11, November 1986, pp. 9 - 16.
[Stroustrup, 1986]. B. Stroustrup, "An Overview of C++," SIGPLAN
Notices, Vol. 21, No. 10, October 1986, pp. 7 - 18.
[Sutherland, 1963]. I. Sutherland, Sketchpad, A Man-Machine Graphical
Communication System, Ph. D. Thesis, Massachusetts Institute of
Technology, January 1963.
[Unger and Smith, 1987]. D. Ungar and R.B. Smith, "Self: The Power of
Simplicity," OOPSLA U87 Conference Proceedings, Special Issue of
SIGPLAN Notices, Vol. 22, No. 12, December 1987, pp. 227 - 242.
[Wegner, 1986]. P. Wegner, "Classification in Object-Oriented
Systems," SIGPLAN Notices, Vol. 21, No. 10, October 1986, pp. 173 -
182.
[Wexelblat, 1981]. R.L. Wexelblat, Editor, History of Programming
Languages, Academic Press, New York, New York, 1981.