Thinking Object Oriented

Home , Alan Kay, Alan Perlis, Fred Brooks

Chapter 1

Thinking Ob ject Oriented

Ob ject-oriented programming has b ecome exceedingly p opular in the past few years. Soft-

ware pro ducers rush to release ob ject-oriented versions of their pro ducts. Countless b o oks

and sp ecial issues of academic and trade journals have app eared on the sub ject. Students

strive to b e able somehow to list \exp erience in ob ject-oriented programming" on their re-

sumes. To judge from this frantic activity, ob ject-oriented programming is b eing greeted

with an even greater p opularity than wehave seen in the past heralding earlier revolutionary

ideas, such as \structured programming" or \exp ert systems".

My intent in this rst chapter is to investigate and explain the basic principles of ob ject

oriented programming, and in doing so to illustrate the following two prop ositions:

OOP is a revolutionary idea, totally unlikeanything that has come b efore in program-

ming.

OOP is an evolutionary step, following naturally on the heels of earlier programming

abstractions.

1.1 Why is Ob ject-Oriented Programming Popular?

To judge from much of the p opular press, the following represent a few of the p ossible

reasons why Ob ject-oriented programming has, in the past decade, b ecome so p opular:

The hop e that it will quickly and easily lead to increased pro ductivity and improved

reliability help solve the software crises.

The desire for an easy transition from existing languages.

The resonant similarity to techniques of thinking ab out problems in other domains. 1

2 CHAPTER 1. THINKING OBJECT ORIENTED

Ob ject-Oriented programming is just the latest in a long series of solutions that have b een

prop osed to help solve the \software crises". At heart, the software crises simply means that

our imaginations, and the tasks wewould like to solve with the help of computers, almost

always nearly outstrip our abilities.

But, while ob ject-oriented techniques do facilitate the creation of complex software sys-

tems, it is imp ortant to rememb er that OOP is not a \silver bullet", a term made p opular

byFred Bro oks [Bro oks 87]. Programming a computer is still one of the most dicult

tasks ever undertaken byhumankind; b ecoming pro cient in programming requires talent,

creativity,intelligence, logic, the ability to build and use abstractions, and exp erience { even

when the b est of to ols are available.

I susp ect another reason for the particular p opularity of languages such as C++ and

Ob ject Pascal as opp osed to languages such as Smalltalk and Beta is that managers and

programmers alikehopethataCorPascal programmer can b e changed into a C++ or

Ob ject Pascal programmer with no more e ort than the addition of twocharacters to the

programmer's job title. Unfortunately, this hop e is a long way from b eing realized. Ob ject-

Oriented programming is a new way of thinking ab out what it means to compute, ab out how

we can structure information inside a computer. To b ecome pro cient in ob ject-oriented

techniques requires a complete reevaluation of traditional software development techniques.

1.2 Language and Thought

\Human b eings do not live in the ob jectiveworld alone, nor alone in the world

of so cial activity as ordinarily understo o d, but are very much at the mercy of

the particular language which has b ecome the medium of expression for their

so ciety. It is quite an illusion to imagine that one adjusts to reality essentially

without the use of language and that language is merely an incidental means of

solving sp eci c problems of communication or re ection. The fact of the matter

is that the `real world' is to a large extent unconsciously built up on the language

habits of the group.... We see and hear and otherwise exp erience very largely as

we do b ecause the language habits of our community predisp ose certain choices

of interpretation."

Edward Sapir quoted in [Whorf 56]

This quote emphasizes the fact that the languages we sp eak in uence directly the wayin

whichwe view the world. This is true not only for natural languages, such as the kind studied

by the early 20th century American linguists Edward Sapir and Benjamin Lee Whorf, but

also for arti cial languages such as those we use in programming computers.

1.2.1 Eskimos and Snow

An almost universally cited example of the phenomenon of languages in uencing thought,

although also an erroneous one see [Pullum 91] is the \fact" that Eskimo or Inuit lan-

1.2. LANGUAGE AND THOUGHT 3

guages have manywords to describ e various typ es of snow{wet, u y, heavy, icy, and so

on. This is not surprising. Any community with common interests will naturally develop a

sp ecialized vo cabulary for concepts they wish to discuss.

What is imp ortant is to not over generalize the conclusion we can draw from this simple

observation. It is not that the Eskimo eyeisinany signi cant resp ect di erent from my

own, or that Eskimos can see things that I can not p erceive. With time and training I could

do just as well at di erentiating typ es of snow. But the language I sp eak namely, English

do es not force me into doing so, and so it is not natural to me. A di erent language such

as Inuktitut thus can lead one but do es not require one to view the world in a di erent

fashion.

To make e ective use of ob ject oriented principles requires one to view the world in a new

fashion. But simply using an ob ject oriented language such as C++ do es not, by itself,

force one to b ecome an ob ject oriented programmer. While the use of an ob ject oriented

language will simplify the development of ob ject oriented solutions, it is true, as it has b een

quipp ed, that \FORTRAN programs can b e written in any language."

1.2.2 An Example from Computer Languages

The relationship we noted b etween language and thought for natural human languages is

even more pronounced in the realm of arti cial computer languages. That is, the language

in which a programmer thinks a problem will b e solved will color and alter, in a basic

fundamental way, the fashion in which an algorithm is develop ed.

An example will help illustrate this relationship b etween computer language and problem

solution. Several years ago a studentworking in genetic researchwas faced with a task

involved in the analysis of DNA sequences. The problem could b e reduced to a relatively

simple form. The DNA is represented as a vector of N integer values, where N is very large

on the order of tens of thousands. The problem was to discover whether any pattern of

length M, where M was a xed and small constant say ve or ten is ever rep eated in the

vector of values.

ACTCGGATCTTGCATTTCGGCAATTGGACCCTGACTTGGCCA ...

The programmer dutifully sat down and wrote a simple and straightforward FORTRAN

program, something like the following:

DO 10 I = 1, N-M

DO 10 J = 1, N-M

FOUND = .TRUE.

DO 20 K = 1, M

20 IF X[I+K-1] .NE. X[J+K-1] THEN FOUND = .FALSE.

IF FOUND THEN ...

10 CONTINUE

4 CHAPTER 1. THINKING OBJECT ORIENTED

The studentwas somewhat disapp ointed when trial runs indicated his program would

need signi cantly many hours to complete. He discussed his problem with a second student,

who happ ened to b e pro cient in the programming language APL. The second student

said that she would like to try writing a program for this problem. The rst studentwas

dubious. After all, FORTRAN was known to b e one of the most \ecient" programming

languages. It was compiled, after all, and APL was only interpreted. Therefore it was with

a certain amount of incredulity that he discovered the APL programmer was able to write

an algorithm that worked in a matter of minutes, not hours.

What the APL programmer had done was to rearrange the problem. Rather than work-

ing with a vector of N elements, she reorganized the data into a matrix with roughly N

rows and M columns:

A C T C G G p ositions 1 to M

C T C G G A p ositions 2 to M +1

T C G G A T p ositions 3 to M +2

C G G A T T p ositions 4 to M +3

G G A T T C p ositions 5 to M +4

G A T T C T p ositions 6 to M +5

. . .

T G G A C C

G G A C C C

. . .

The APL programmer then sorted this matrix byrows. If any pattern was rep eated,

then two adjacentrows in the sorted matrix would have identical values.

. . .

T G G A C C

. . .

It was a trivial matter to check for this condition. The reason the APL program was

faster had nothing to do with the sp eed of APL versus FORTRAN, but was simply b ecause

the FORTRAN program employed an algorithm that was O M N , whereas the sorting

solution used by the APL programmer required approximately O M N log N op erations.

The p oint of this story is not to indicate that APL is in anyway a \b etter" programming

language than FORTRAN, but to ask whyitwas that the APL programmer was naturally

led to discover a b etter solution. The reason, in this case, is that lo ops are very dicult

to write in APL, whereas sorting is trivial; it is a built-in op erator de ned as part of the

language. Thus, b ecause the op eration is so easy to p erform, go o d APL programmers tend

to lo ok for novel applications for sorting. It is in this manner that the programming language

in which the solution is to b e written directs the programmer's mind to view the problem in one fashion or another.

1.2. LANGUAGE AND THOUGHT 5

1.2.3 Church's Conjecture and the Sapir-Whorf Hyp othesis

The assertion that the language in which an idea is expressed can in uence or direct a line

of thought is relatively easy to b elieve. It should b e noted, however, a stronger conjec-

ture, known in linguistics as the Sapir-Whorf hyp othesis, go es much further and remains

controversial [Pullum 91].

The Sapir-Whorf hyp othesis asserts that it may b e p ossible for an individual working

in one language to imagine thoughts or utter ideas which cannot in anyway b e translated,

cannot even b e understo o d, by individuals op erating in a di erent linguistic framework.

According to advo cates of the hyp othesis, this can o ccur when the language of the second

individual has no equivalentwords, and lacks even concepts or categories for the ideas

involved in the thought. It is interesting to compare this idea with an almost directly

opp osite concept from computer science, namely Church's conjecture.

Starting in the 1930's and on through the 40's and 50's there was a great deal of

interest within the mathematical and nascent computing communityinavariety of for-

malisms that could b e used for the calculation of functions. Examples include the notations

prop osed byChurch [Church 36], Post [Post 36], Markov [Markov 51], Turing [Turing 36],

Kleene [Kleene 36] and others. Over time a numb er of arguments were put forth to demon-

strate that many of these systems could b e used in the simulation of others. Often, for a

pair of systems, such arguments could b e made in b oth directions; e ectively showing that

the systems were identical in computation p ower. The sheer numberofsuch arguments lead

the logician Alonzo Church to pronounce a conjecture that is now asso ciated with his name:

Church's Conjecture: Any computation for which there exists an e ective

pro cedure can b e realized bya Turing machine.

By nature this conjecture must remain unproven and unprovable, since wehaveno

rigorous de nition of the term \e ective pro cedure." Nevertheless, no counterexample has

yet b een found, and the weight of evidence seems to favor armation of this claim.

Acceptance of Church's conjecture has an imp ortant and profound implication for the

study of programming languages. Turing machines are wonderfully simple mechanisms,

and it do es not require many features in a language in order to b e able to simulate such

a device. In the 1960's, for example, it was demonstrated that a Turing machine could

be emulated in any language that p ossessed at least a conditional statement and a lo oping

construct [Bohm 66]. This greatly misundersto o d result was the ma jor ammunition used

to \prove" that the infamous goto statementwas unnecessary.

If we accept Church's conjecture, then any language in which it is p ossible to simulate

aTuring machine is suciently p owerful to p erform any realizable algorithm. To solve

a problem, nd the Turing machine that pro duces the desired result, whichbyChurch's

conjecture must exist, then simulate the execution of the Turing machine in your favorite

language. Thus, arguments ab out the relative\power" of programming languages, if by

power we mean \ability to solve problems," are generally vacuous. The late Alan Perlis had

6 CHAPTER 1. THINKING OBJECT ORIENTED

a term for such arguments, calling them a \Turing Tarpit," since they are often so dicult

to extricate oneself from, and so fundamentally p ointless.

Note that Church's conjecture is, in a certain sense, almost the exact opp osite of the

Sapir-Whorf hyp othesis. Church's conjecture states that in a fundamental fashion all pro-

gramming languages are identical. Any idea that can b e expressed in one language can, in

theory, b e expressed in any language. The Sapir-Whorf hyp othesis, you will recall, claimed

that it was p ossible for ideas to b e expressed in one language that could not b e expressed

in another.

Many linguists reject the Sapir-Whorf hyp othesis and instead adopt a sort of \Turing-

equivalence" for natural languages. By this we mean that, with a sucient amountofwork,

any idea can b e expressed in any language. For example, while the language sp oken bya

nativeofawarm climate may not make it instinctive to examine a eld a snow and categorize

it with resp ect to di erenttyp es or uses, with time and training it certainly can b e learned.

Similarly, ob ject-oriented techniques do not provide any new computational p ower which

p ermits problems to b e solved that cannot, in theory b e solved by other means. But ob ject-

oriented techniques do makeiteasier and more natural to address problems in a fashion

that tends to favor the management of large software pro jects.

Thus, for b oth computer and natural languages it is the case that the language will direct

thoughts, but cannot proscribe thoughts.

1.3 A New Paradigm

Ob ject-oriented programming is often referred to as a new programming paradigm. Other

programming paradigms sometimes mentioned include the imp erative-programming paradigm

languages suchasPascal or C, the logic programming paradigm Prolog, and the functional-

programming paradigm FP or Haskell.

It is interesting to examine the de nition of the word \paradigm": The following is from

the American Heritage Dictionary of the English Language:

par a digm n. 1. A list of all the in ectional forms of a word taken as

an illustrative example of the conjugation or declension to which it b elongs. 2.

Any example or mo del. [Late Latin parad gma, from Greek paradeigma, mo del,

from paradeiknunai, to compare, exhibit.]

At rst blush, the conjugation or declension of Latin words would seem to have little

to do with computer programming languages. To understand the connection, wemust note

that the word was brought backinto the mo dern vo cabulary through an in uential b o ok

called The Structure of Scienti c Revolutions, authored by the historian of science Thomas

Kuhn [Kuhn 70]. Kuhn used the term in the second form, to describ e a set of theories,

standards and metho ds that together representaway of organizing knowledge; that is, a

way of viewing the world. Kuhn's thesis was that revolutions in science o ccurred when an

older paradigm was reexamined, rejected and replaced by another.

1.4. A WAY OF VIEWING THE WORLD 7

It is in this sense, as a mo del or example, and as an organizational approach, that Rob ert

Floyd used the term in his 1979 ACM Turing Award lecture [Floyd 79], whichwas titled

\The Paradigms of Programming". A programming paradigm is a way of conceptualizing

what it means to p erform computation, and how tasks that are to b e carried out on a

computer should b e structured and organized.

Although new to computation, the organizing technique that lies at the heart of ob ject-

oriented programming can b e traced back through the history of science in general at least

as far as Linnus 1707-1778, if not even further back to the Greek philosopher Plato.

Paradoxically, the style of problem solving emb o died in the ob ject-oriented technique is

frequently the metho d used to address problems in everyday life. Thus, computer novices

are often able to grasp the basic ideas of ob ject-oriented programming easily, whereas those

p eople who are more computer literate are often blo cked by their own preconceptions. Alan

Kay, for example, found that it was usually easier to teach Smalltalk to children than to

computer professionals [Kay77].

In trying to understand exactly what is meantby the term object-orientedprogramming,

it is p erhaps useful to examine the idea from several alternative p ersp ectives. The next few

sections outline three di erent asp ects of ob ject-oriented programming; each illustrates a

particular reason why this technique should b e considered an imp ortant new to ol.

1.4 AWay of Viewing the World

To illustrate some of the ma jor ideas in ob ject-oriented programming, let us consider rst

howwe might go ab out handling a real-world situation, and then ask howwe could make

the computer more closely mo del the techniques employed.

Supp ose I wish to send some owers to my grandmother who is named Elsie for her

birthday. She lives in a city many miles away, so the p ossibilityofmy picking the owers

and carrying them myself to her do or is out of the question. Nevertheless, sending her the

owers is a task easy enough to do; I merely go down to my lo cal orist who happ ens to b e

named Flo, describ e the kinds and numb ers of owers I want sent, and my grandmother's

address, and I can b e assured the owers will b e delivered exp ediently and automatically.

1.4.1 Agents, Resp onsibility, Messages and Metho ds

At the risk of b elab oring a p oint, let me emphasize that the mechanism I used to solve

my problem was to nd an appropriate agent namely Flo, and to pass to her a message

containing my request. It is the responsibility of Flo to satisfy my request. There is some

method { that is, some algorithm or set of op erations { used by Flo to do this. I do not

need to know the particular metho d Flo will use to satisfy my request; indeed, often I do

not want to know the details. This information is usually hidden from my insp ection.

If I investigated, however, I might discover that Flo delivers a slightly di erent message

to another orist in my grandmother's city. That orist, in turn, makes the arrangement

8 CHAPTER 1. THINKING OBJECT ORIENTED

and passes it, along with yet another message, to a delivery p erson, and so on. In this

manner my request is nally satis ed by a sequence of requests from one agent to another.

So our rst principle of ob ject-oriented problem solving is the vehicle by which activities

are initiated:

Action is initiated in ob ject-oriented programming by the transmission of a

message to an agent an object resp onsible for the action. The message enco des

the request for an action, and is accompanied byany additional information ar-

guments needed to carry out the request. The receiver is the agent to whom the

message is sent. If the receiver accepts the message, it accepts the resp onsibility

to carry out the indicated action. In resp onse to a message, the receiver will

p erform some method to satisfy the request.

Wehave noted the imp ortant principle of information hiding in regard to message passing

{ that is, the client sending the request need not know the actual means by which the

request will b e honored. There is another principle, all to o human, that we can also observe

is implicit in message passing. That principle is, if there is a task to p erform, the rst

thought of the client is to nd someb o dy else whom it can ask to do the work. It is

interesting to note the degree to which this second reaction will often b ecome atrophied in

many programmers with extensive exp erience in using conventional techniques. Frequently,

a dicult hurdle to overcome is the idea in the programmers mind that he or she must

write everything themselves, and not use the services of others. An imp ortant part of

ob ject-oriented programming is the development of reusable comp onents, and an imp ortant

rst step in the use of reusable comp onents is a willingness to use an already develop ed

comp onent.

Information hiding is also an imp ortant asp ect of programming in conventional lan-

guages. In what sense is a message di erent from, say, a pro cedure call? In b oth cases,

there is a set of well-de ned steps that will b e initiated following the request.

There are two imp ortant distinctions. The rst is that in a message there is a designated

receiver for that message; the receiver is some agent to whom the message is sent. In a

pro cedure call, there is no designated receiver. Although we could adapt a convention of,

for example, always calling the rst argument to a pro cedure the receiver, something that

is very close to how receivers are actually implemented.

The second is that the interpretation of the message that is, the metho d used to resp ond

to the message is dep endent on the receiver, and can vary with di erent receivers. I can

give exactly the same message to my wife Beth, for example, and she will understand the

message and a satisfactory outcome will b e pro duced that is, owers will b e delivered to

my grandmother. However, the metho d Beth uses to satisfy the request in all likeliho o d,

simply passing the request on to Flo, will b e di erent from that p erformed by Flo in

resp onse to the same request. If I ask Ken, my dentist, to send owers to my grandmother,

I probably would b e making an error, since Ken may not have a metho d for solving that

problem. If he understo o d the request at all, he would probably issue an appropriate error diagnostic.

1.4. A WAY OF VIEWING THE WORLD 9

Let us move our discussion back to the level of computers and programs. There, the

distinction b etween message passing and pro cedure calling is that, in message passing, there

is a designated receiver, and the interpretation { that is, the selection of a metho d to execute

in resp onse to the message { mayvary with di erent receivers. Usually, the sp eci c receiver

for any given message will not b e known until run time, so the determination of which

metho d to invoke cannot b e made until then. Thus, wesay there is late binding between

the message function or pro cedure name and the co de fragment metho d used to resp ond

to the message. This situation is in contrast to the very early compile-time or link-time

binding of name to co de fragmentinconventional pro cedure calls.

1.4.2 Resp onsibilities

A fundamental concept in ob ject-oriented programming is to describ e b ehavior in terms of

responsibilities. My request for action indicates only the desired outcome owers for my

grandmother. The orist is free to pursue any technique that achieves the desired ob jective,

and is not hamp ered byinterference on my part.

By discussing a problem in terms of resp onsibilities we increase the level of abstraction.

This p ermits greater independence between agents, a critically imp ortant factor in solving

complex problems. In Chapter 2 we will investigate in more detail howwe can use an

emphasis on resp onsibility to drive the software design pro cess. The entire collection of

resp onsibilities asso ciated with an ob ject is often describ ed by the term protocol.

The di erence b etween viewing software in traditional structured terms and viewing

software in an ob ject-oriented p ersp ective can b e summarized byatwist on a well-known

quote:

\Ask not what you can do to your data structures,

but rather ask what your data structures can do for you"

1.4.3 Classes and Instances

Although I have only dealt with Flo a few times in the past, I have a rough idea of the

b ehavior I can exp ect when I go into her shop and present her with my request. I am able

to make certain assumptions b ecause I have some information ab out orists in general, and

I exp ect that Flo, b eing an instance of this category, will t the general pattern. We can

use the term Florist to represent the category or class of all orists. Let us incorp orate

these notions into our second principle of ob ject-oriented programming:

All ob jects are instances of a class. The metho d invoked by an ob ject in

resp onse to a message is determined by the class of the receiver. All ob jects of

a given class use the same metho d in resp onse to similar messages.

One current problem in the ob ject-oriented community is the proliferation of di erent

terms for similar ideas. Thus, a class is known in Ob ject Pascal as an object type, and a

10 CHAPTER 1. THINKING OBJECT ORIENTED

ancestor class whichwe will describ e shortly, is known as a superclass or parent class, and

so on. The glossary at the end of this b o ok should b e of some help with unusual terms. We

will use the convention, common in ob ject-oriented languages, of always designating classes

by a name b eginning with an upp ercase letter. Although commonly used, this convention

is not enforced by most language systems.

1.4.4 Class Hierarchies { Inheritance

There is more information I have ab out Flo { not necessarily b ecause she is a orist, but

b ecause she is a shopkeep er. I know, for example, that I probably will b e asked for money

as part of the transaction, and in return for payment I will b e given a receipt. These actions

are true of gro cers, of stationers, and of other shopkeep ers. Since the category Florist is a

more sp ecialized form of the category Shopkeep er,any knowledge I haveofShopkeep ers

is also true of Florists, and hence of Flo.

One way to think ab out howIhave organized my knowledge of Flo is in terms of a

hierarchy of categories see Figure 1.1. Flo is a Florist, but Florist is a sp ecialized form

of Shopkeep er.Furthermore, a Shopkeep er is also a Human; so I know, for example,

that Flo is probably bip edal. A Human is a Mammal therefore they nurse their young,

and a Mammal is an Animal therefore it breathes oxygen, and an Animal is a Material

Ob ject therefore it has mass and weight. Thus, there is quite a lot of knowledge I have

that is applicable to Flo that is not directly asso ciated with her, or even with her category

Florist.

The principle that knowledge of a more general category is applicable also to the more

sp eci c category is called inheritance.Wesay that the class Florist will inherit attributes

of the class or category Shopkeep er.

There is an alternative graphical technique that is often used to illustrate this relation-

ship, particularly when there are many individuals with di ering lineage's. This technique

shows classes listed in a hierarchical tree-like structure, with more abstract classes suchas

Material Ob ject or Animal listed near the top of the tree, and more sp eci c classes,

and nally individuals, listed near the b ottom. Figure 1.2 shows this class hierarchy for Flo.

This hierarchy also includes Beth, my dog Flash, Phyl the platypus who lives at the zo o,

and the owers themselves that I am sending to my grandmother.

Information that I p ossess ab out Flo b ecause she is an instance of class Human is also

applicable to my wife Beth, for example. Information that I have ab out her b ecause she

is a Mammal is applicable to Flash as well. Information ab out all memb ers of Material

Ob ject is equally applicable to Flo and to her owers. We capture this in the idea of

inheritance:

Classes can b e organized into a hierarchical inheritance structure. A child

class or subclass will inherit attributes from a parent class higher in the tree.

An abstract parent class is a class suchasMammal that is used only to create

sub classes, for which there are no direct instances.

1.4. A WAY OF VIEWING THE WORLD 11

' $

Material Object

' $

Animal

' $

Mammal

' $

Human

' $

Shopkeep er

$ '

Florist

Flo

& Figure 1.1: The categories surrounding Flo

12 CHAPTER 1. THINKING OBJECT ORIENTED

Material Objects

Animal Plant

Mammal Flower

@ X

X @

Dog Human Platypus

B H

Shopkeep er Artist Dentist

Florist Potter

Flash Flo Beth Ken Phyl grandma's owers

Figure 1.2: A class hierarchy for various material ob jects

1.4.5 Metho d Binding, Overriding and Exceptions

Phyl the platypus presents a problem for our simple organizing structure. I know that

mammals give birth to livechildren, for example, and Phyl is certainly a Mammal, and yet

Phyl or rather his mate, Phyllis continues to lay eggs. To accommo date this, we need to

nd a technique to enco de exceptions to a general rule.

We do this by decreeing that information contained in a sub class can override information

inherited from a parent class. Most often, implementations of this approach takes the form

of a metho d in a sub class having the same name as a metho d in the parent class, combined

with a rule for how the search for a metho d to match a sp eci c message is conducted:

The search to nd a metho d to invoke in resp onse to a given message b egins

1.4. A WAY OF VIEWING THE WORLD 13

with the class of the receiver. If no appropriate metho d is found, the searchis

conducted in the parent class of this class. The search continues up the parent

class chain until either a metho d is found, or the parent class chain is exhausted.

In the former case the metho d is executed; in the latter case, an error message

is issued.

If metho ds with the same name can b e found higher in the class hierarchy,

the metho d executed is said to override the inherited b ehavior.

Even if the compiler cannot determine which metho d will b e invoked at run time, in many

ob ject-oriented languages it can determine whether there will b e an appropriate metho d and

issue an error message as a compile-time error diagnostic, rather than as a run time message.

We will discuss the mechanism for overriding in various computer languages in Chapter 11.

That my wife Beth and my orist Flo will resp ond to my message by p erforming di erent

metho ds is an example of one form of polymorphism.We will discuss this imp ortant part of

ob ject-oriented programming in Chapter 14. As we explained, that I do not, and need not,

know exactly what metho d Flo will use to honor my message is an example of information

hiding, whichwe will discuss in Chapter 17.

1.4.6 Summary of Ob ject-Oriented Concepts

Alan Kay, considered by some to b e the father of ob ject-oriented programming, has identi ed

the following characteristics as fundamental to OOP: [Kay 93]

1. Everything is an object.

2. Computation is p erformed by ob jects communicating with each other, requesting that

other ob jects p erform actions. Ob jects communicate by sending and receiving mes-

sages. A message is a request for action bundled with whatever arguments maybe

necessary to complete the task.

3. Each ob ject has its own memory, which consists of other ob jects.

4. Every ob ject is an instance of a class. A class simply represents a grouping of similar

ob jects, suchasintegers, or lists.

5. The class is the rep ository for behavior asso ciated with an ob ject. That is, all ob jects

that are instances of the same class can p erform the same actions.

6. Classes are organized into a singly-ro oted tree structure, called the inheritance hier-

archy. Memory and b ehavior asso ciated with instances of a class are automatically

available to any class asso ciated with a descendent in this tree structure.

14 CHAPTER 1. THINKING OBJECT ORIENTED

i: j:

2 3

'$'$

a[1]: a[2]: a[3]: a[4]:

4 6 2 4

Figure 1.3: Visualization of Imp erative Programming

1.5 Computation as Simulation

The view of programming that is represented by the example of sending owers to my

grandmother is very di erent from the conventional conception of a computer. The tradi-

tional mo del describing the b ehavior of a computer executing a program is a process-state

or pigeon-hole mo del. In this view, the computer is a data manager, following some pattern

of instructions, wandering through memory, pulling values out of various slots memory

addresses, transforming them in some manner, and pushing the results backinto other

slots see Figure 1.3. By examining the values in the slots, we can determine the state

of the machine or the results pro duced by a computation. Although this mo del maybea

more or less accurate picture of what takes place inside a computer, it do es little to help us

understand how to solve problems using the computer, and it is certainly not the way most

p eople pigeon handlers and p ostal workers excepted go ab out solving problems.

In contrast, in the ob ject-oriented framework, we never mentioned memory addresses or

variables or assignments or any of the conventional programming terms. Instead, wespoke

of ob jects, messages, and resp onsibility for some action. In Dan Ingalls memoriable phrase:

\Instead of a bit-grinding pro cessor...plundering data structures, wehavea

universe of well-b ehaved ob jects that courteously ask each other to carry out

their various desires" [Ingalls 81].

Another author has describ ed ob ject-oriented programming as \animistic;" a pro cess

1.5. COMPUTATION AS SIMULATION 15

of creating a host of help ers that forms a community and assists the programmer in the

solution of a problem [Actor 87].

This view of programming as creating a \universe" is in manyways similar to a style

of computer simulation called \discrete event-driven simulation." In brief, in a discrete

event-driven simulation, the user creates computer mo dels of the various elements of the

simulation, describ es how they will interact with one another, and sets them moving. This

is almost identical to the average ob ject-oriented program, in which the user describ es what

the various entities in the universe for the program are, and how they will interact with one

another, and nally sets them in motion. Thus, in ob ject-oriented programming, wehave

the view that computation is simulation [Kay 77].

1.5.1 The Power of Metaphor

An easily overlo oked b ene t to the use of ob ject-oriented techniques is the p ower of metaphor.

When programmers think ab out problems in terms of b ehaviors and resp onsibilities of ob-

jects, they bring with them a wealth of intuition, ideas, and understanding from their

everyday exp erience. When computing is thought of in terms of pigeon-holes, mailb oxes, or

slots containing values, there is little in the average programmer's background to provide

an intuitive insightinto how problems should b e structured.

Although anthrop omorphic descriptions such as the quote by Ingalls given previously

may strike some p eople as o dd, in fact they are a re ection of the great exp ositivepower

of metaphor. Journalists make use of the p ower of metaphor every day, as in the following

description of ob ject-oriented programming, from the news magazine Newsweek:

\Unlike the usual programming metho d { writing software one line at a time

{ NeXT's `ob ject-oriented' system o ers larger building blo cks that develop ers

can quickly assemble the way a kid builds faces on Mr. Potato Head."

It is p ossibly this feature, more than any other, that is resp onsible for the frequently ob-

served phenomenon that it is often easier to teach ob ject-oriented programming concepts to

computer novices than to computer professionals. Novice users quickly adapt the metaphors

with which they are already comfortable from their everyday life, whereas seasoned computer

professionals are blinded by an adherence to more traditional ways of viewing computation.

1.5.2 Avoiding In nite Regress

Of course, ob jects cannot always resp ond to a message by p olitely asking another ob ject to

p erform some action. The result would b e an in nite circle of requests, liketwo gentlemen

each p olitely waiting for the other to go rst b efore entering a do orway,orlike a bureaucracy

of pap er pushers, each passing on all pap ers to some other memb er of the organization. At

some p oint, at least a few ob jects need to p erform some work other than passing on requests

to other agents. This work is accomplished di erently in various ob ject-oriented languages.

16 CHAPTER 1. THINKING OBJECT ORIENTED

In blended ob ject-oriented/imp erative languages, such as C++, Ob ject Pascal, and

Ob jective-C, it is accomplished by metho ds written in the base non-ob ject-oriented lan-

guage. In pure ob ject-oriented languages, such as Smalltalk or Java, it is accomplished by

the intro duction of \primitive" or \native" op erations that are provided by the underlying

system.

1.6 Coping with Complexity

When computing was in its infancy, most programs were written in assembly language,

by a single individual, and would not b e considered large bytoday's standards. Even

so, as programs b ecame more complex, programmers found that they had a dicult time

rememb ering all the information they needed to know in order to develop or debug their

software. Whichvalues were contained in what registers? Did a new identi er name con ict

with any other previously de ned name? What variables needed to b e initialized b efore

control could b e transferred to another section of co de?

The intro duction of higher-level languages, suchasFortran, Cob ol and Algol, solved

some diculties such as automatic management of lo cal variables, and implicit matching

of arguments to parameters, while simultaneously raising p eople's exp ectations of what a

computer could do in a manner that only intro duced yet new problems. As programmers

attempted to solveever more complex problems using a computer, tasks exceeding in size

the grasp of even the b est programmers b ecame the norm. Thus, teams of programmers

working together to undertake ma jor programming e orts b ecame commonplace.

1.6.1 The Nonlinear Behavior of Complexity

As programming pro jects b ecame larger, an interesting phenomenon was observed. A task

that would take one programmer 2 months to p erform could not b e accomplished bytwo

programmers working for 1 month. In Fred Bro oks's memorable phrase, \the b earing of a

child takes nine months, no matter how manywomen are assigned to the task" [Bro oks 75].

The reason for this nonlinear b ehavior was complexity { in particular, the intercon-

nections b etween software comp onents were complicated, and large amounts of information

had to b e communicated among various memb ers of the programming team. Bro oks further

said:

\Since software construction is inherently a systems e ort { an exercise in

complex interrelationships { communication e ort is great, and it quickly domi-

nates the decrease in individual task time brought ab out by partitioning. Adding

more men then lengthens, not shortens, the schedule" [Bro oks 75].

What brings ab out this complexity? It is not simply the sheer size of the tasks un-

dertaken, b ecause size by itself would not b e a hindrance to partitioning eachinto several

pieces. The unique feature of software systems develop ed using conventional techniques that

1.6. COPING WITH COMPLEXITY 17

makes them among the most complex systems develop ed by p eople is their high degree of

interconnectedness. Interconnectedne ss means the dep endence of one p ortion of co de on

another section of co de.

Consider that any p ortion of a software system must b e p erforming an essential task, or

it would not b e there. Now, if this task is useful to the other parts of the program, there

must b e some communication of information either into or out of the comp onent under

consideration. Because of this, a complete understanding of what is going on requires a

knowledge b oth of the p ortion of co de we are considering and the co de that uses it. In

short, an individual section of co de cannot b e understo o d in isolation.

1.6.2 Abstraction Mechanisms

Programmers have had to deal with the problem of complexity for a long time in the history

of computer science. To understand more fully the imp ortance of ob ject-oriented techniques,

we should review the variety of mechanisms programmers have used to control complexity.

Chief among these is abstraction, the ability to encapsulate and isolate design and execution

information. In one sense, ob ject-oriented techniques are not revolutionary at all, but can b e

seen to b e a natural outcome of a long historical progression from pro cedures, to mo dules,

to abstract data typ es and nally to ob jects.

Pro cedures

Pro cedures and functions were one of the rst abstraction mechanisms to b e widely used in

programming languages. Pro cedures allowed tasks that were executed rep eatedly,orwere

executed with only slightvariations, to b e collected in one place and reused, rather than

the co de b eing duplicated several times. In addition, the pro cedure gave the rst p ossibility

for information hiding. One programmer could write a pro cedure, or a set of pro cedures,

that were used by many others. The other programmers did not need to know the exact

details of the implementation - they needed only the necessary interface. But pro cedures

were not an answer to all problems. In particular, they were not an e ective mechanism

for information hiding, and they only partially solved the problem of multiple programmers

making use of the same names.

Example { A Stack

To illustrate these problems, we can consider a programmer who must write a set of routines

to implement a simple stack. Following go o d software engineering principles, our program-

mer rst establishes the visible interface to his or her work { say, a set of four routines:

init, push, pop, and top. She then selects some suitable implementation technique. Here,

there are manychoices, such as an array with a top-of-stack p ointer, a linked list, and so

on. Our intrepid programmer selects from among these choices, then pro ceeds to co de the

utilities, as shown in Figure 1.4.

18 CHAPTER 1. THINKING OBJECT ORIENTED

int datastack[100];

int datatop = 0;

void init

datatop = 0;

void pushint val

datastack [datatop++] = val;

int top

return datastack [datatop - 1];

int pop

return datastack [--datatop];

Figure 1.4: Failure of pro cedures in information hiding

It is easy to see that the data contained in the stack itself cannot b e made lo cal to any

of the four routines, since they must b e shared by all. But if the only choices are lo cal

variables or global variables as they are in FORTRAN, or in C prior to the intro duction

of the static mo di er, then the stack data must b e maintained in global variables. But if

the variables are global, then there is no way to limit the accessibility or visibility of these

names. For example, if the stack is represented in an array named datastack, this fact

must b e made known to all the other programmers, since they maywant to create variables

using the same name and should b e discouraged from doing so. This is true even though

these data values are imp ortant to only the stack routines, and should not haveany use

outside of these four pro cedures. Similarly, the names init, push, pop, and top are now

reserved, and cannot b e used in other p ortions of the program for other purp oses, even if

those sections of co de have nothing to do with the stack routines.

1.6. COPING WITH COMPLEXITY 19

Blo ck Scoping

The blo ck scoping mechanism of Algol and its successors, suchasPascal, o ers slightly

more control over name visibility than do es a simple distinction b etween lo cal and global

names. At rst, we might b e tempted to hop e that this abilitywould solve the information-

hiding problem. Unfortunately, it do es not. Any scop e that p ermits access to the four

named pro cedures must also p ermit access to their common data. To solve this problem, a

di erent structuring mechanism had to b e develop ed.

begin

var

datastack : array [ 1 .. 100 ] of integer;

datatop : integer;

procedure init;

...

procedure pushval : integer;

...

function pop : integer;

...

end;

Mo dules

In one sense, mo dules can b e viewed simply as an improved technique for creating and

managing collections of names and their asso ciated values. Our stack example is typical,

in that there is some information the interface routines that wewant to b e widely and

publicly available, whereas there are other data values the stack data themselves that we

want restricted. Stripp ed to its barest form, a module provides the ability to divide a name

space into two parts. The public part is accessible outside the mo dule, whereas the private

part is accessible only within the mo dule. Typ es, data variables and pro cedures can all

b e de ned in either p ortion.

David Parnas, who p opularized the notion of mo dules, describ ed in [Parnas 72] the

following two principles for their prop er use:

1. One must provide the intended user with all the information needed to use the mo dule

correctly, and with nothing more.

2. One must provide the implementor with all the information needed to complete the

mo dule, and nothing more.

20 CHAPTER 1. THINKING OBJECT ORIENTED

The philosophyismuch like the military do ctrine of \need to know;" if you do not need

to know some information, you should not have access to it. This explicit and intentional

concealment of information is known as information hiding.

Mo dules solve some, but not all, of the problems of software development. For example,

mo dules will p ermit our programmer to hide the implementation details of her stack, but

what if the other users wanttohavetwo or more stacks?

As a more extreme example, supp ose a programmer announces that she has develop ed a

new typ e of numeric abstraction, called Complex. She has de ned the arithmetic op erations

for complex numb ers - addition, subtraction, multiplication, and so on. She has de ned

routines to convert from conventional numb ers to complex. There is just one small problem:

you can manipulate only one complex numb er.

The complex numb er system would not b e useful with this restriction, but this is just the

situation in whichwe nd ourselves with simple mo dules. Mo dules by themselves provide

an e ective metho d of information hiding, but do not allow us to p erform instantiation,

which is the ability to makemultiple copies of the data areas. To handle the problem of

instantiation, computer scientists needed to develop a new concept.

Abstract Data Typ es

An abstract data type is a programmer-de ned data typ e that can b e manipulated in a

manner similar to the system-de ned data typ es. As with system de ned typ es, an abstract

data typ e corresp onds to a set p erhaps in nite in size of legal data values and a number

of primitive op erations that can b e p erformed on those values. Users can create variables

with values that range over the set of legal values, and can op erate on those values using

the de ned op erations. For example, our intrepid programmer could de ne her stackasan

abstract data typ e, and the stack op erations as the only legal op erations that are allowed

to b e p erformed on instances of the stack.

Mo dules are frequently used as an implementation technique for abstract data typ es,

although we emphasize that mo dules are an implementation technique, and the abstract

data typ e is a more theoretical concept. The two are related, but are not identical. To build

an abstract data typ e, wemust b e able:

1. To exp ort a typ e de nition

2. To makeavailable a set of op erations that can b e used to manipulate instances of the

typ e

3. To protect the data asso ciated with the typ e so that they can b e op erated on only by

the provided routines

4. To makemultiple instances of the typ e

Mo dules, as wehave de ned them, serve only as an information-hiding mechanism, and

thus directly address only abilities 2 and 3, although the others can b e accommo dated using

1.7. REUSABLE SOFTWARE 21

appropriate programming techniques. Packages, found in languages such as CLU or Ada,

are an attempt to address more directly the issues involved in de ning abstract data typ es.

In a certain sense, an ob ject is simply an abstract data typ e. People have said, for

example, that Smalltalk programmers write the most \structured" of all programs, b ecause

they cannot write anything but de nitions of abstract data typ es. Although it is true that

an ob ject de nition is an abstract data typ e, the notions of ob ject-oriented programming

build on the ideas of abstract data typ es, and add to them imp ortant innovations in co de

sharing and reusability.

Ob jects { Messages, Inheritance and Polymorphism

The techniques of ob ject-oriented programming add several imp ortant new ideas to the

concept of the abstract data typ e. Foremost among these is the idea of message passing.

Activity is initiated byarequest b eing made to a sp eci c ob ject, not by a function using

sp eci c data b eing invoked. In large part, this is merely a change of emphasis; the conven-

tional view places the primary imp ortance on the op eration, whereas the ob ject-oriented

view places primary imp ortance on the value itself. Do you call the push routine with a

stack and a data value, or do you ask a stack to push avalue on to itself ? If this were

all there is to ob ject-oriented programming, the technique would not b e considered a ma jor

innovation. But added to message passing are p owerful mechanisms for overloading names

and reusing software.

Implicit in message passing is the idea that the interpretation of a message can vary with

di erent ob jects. That is, the b ehavior and resp onse that the message elicits will dep end

up on the ob ject receiving the message. Thus, push can mean one thing to a stack, and a

very di erent thing to a mechanical-arm controller. Since names for op erations need not b e

unique, simple and direct forms can b e used, leading to more readable and understandable

co de.

Finally, ob ject-oriented programming adds the mechanisms of inheritance and polymor-

phism. Inheritance allows di erent data typ es to share the same co de, leading to a reduction

in co de size and an increase in functionality.Polymorphism allows this shared co de to b e

tailored to t the sp eci c circumstances of each individual data typ e. The emphasis on

the indep endence of individual comp onents p ermits an incremental development pro cess, in

which individual software units are designed, programmed and tested b efore b eing combined

into a large system.

We will describ e all of these ideas in more detail in subsequentchapters.

1.7 Reusable Software

People have asked for decades why the construction of software could not mirror more

closely the construction of other material ob jects. When we construct a building, a car,

or an electronic device, for example, wetypically piece together a numb er of o -the-shelf

22 CHAPTER 1. THINKING OBJECT ORIENTED

comp onents, rather than fabricating each new element from scratch. Could not software b e

constructed in the same fashion?

In the past, software reusability has b een a much sought-after and seldom-achieved goal.

A ma jor reason for this is the tightinterconnectedness of most software that has b een

constructed in a conventional manner. As we discussed in an earlier section, it is dicult

to extract from one pro ject elements of software that can b e easily used in an unrelated

pro ject, b ecause each p ortion of co de typically has interdep endencies with all other p ortions

of co de. These interdep endencies may b e a result of data de nitions, or may b e functional

dep endencies.

For example, organizing records into a table and p erforming indexed lo okup op erations

on this table are p erhaps some of the most common op erations in programming. Yet table-

lo okup routines are almost always written over again for each new application. Why?

Because, in conventional languages, the record format for the elements is tightly b ound

with the more general co de for insertion and lo okup. It is dicult to write co de that can

work for arbitrary data, for any record typ e.

Ob ject-oriented techniques provide a mechanism for cleanly separating the essential in-

formation insertion and retrieval from the inconsequential information the format for

particular records. Thus, using ob ject-oriented techniques, we can construct large reusable

software comp onents. Many such packages of commercial software comp onents are now

available, and the developing of such reusable comp onents is a rapidly increasing part of the

software industry.

1.8 Summary

Ob ject-oriented programming is not simply a few new features added to programming

languages. Rather, it is a new wayofthinking ab out the pro cess of decomp osing

problems and developing programming solutions.

Ob ject-oriented programming views a program as a collection of largely autonomous

agents, called objects. Each ob ject is resp onsible for sp eci c tasks. It is by the interac-

tion of ob jects that computation pro ceeds. In a certain sense, therefore, programming

is nothing more or less than the simulation of a mo del universe.

An ob ject is an encapsulation of state data values and behavior op erations. Thus,

an ob ject is in manyways similar to a mo dule, or an abstract data typ e.

The b ehavior of ob jects is dictated by the ob ject's class.Every ob ject is an instance

of some class. All instances of the same class will b ehave in a similar fashion that is,

invoke the same metho d in resp onse to a similar request.

An ob ject will exhibit its b ehavior byinvoking a metho d similar to executing a

pro cedure in resp onse to a message. The interpretation of the message that is, the

1.8. SUMMARY 23

sp eci c metho d p erformed is decided by the ob ject, and may di er from one class of

ob jects to another.

Ob jects and classes extend the concept of abstract data typ es by adding the notion

of inheritance. Classes can b e organized into a hierarchical inheritance tree. Data

and b ehavior asso ciated with classes higher in the tree can also b e accessed and used

by classes lower in the tree. Such classes are said to inherit their b ehavior from the

parent classes.

By reducing the interdep endency among software comp onents, ob ject-oriented pro-

gramming p ermits the development of reusable software systems. Such comp onents

can b e created and tested as indep endent units, in isolation from other p ortions of a

software application.

Reusable software comp onents p ermit the programmer to deal with problems on a

higher level of abstraction. We can de ne and manipulate ob jects simply in terms of

the messages they understand and a description of the tasks they p erform, ignoring

implementation details.