[PDF] - P art I Understanding the Ob ject-Orien ted W orld View 11 PDF Document

SLIDE 1 P art I Understanding the Ob ject-Orien ted W

rld

SLIDE 2

SLIDE 3 Chapter 1 Ob ject-Orien ted Thinking This is a b

k

ab

ut
b

ject-orien ted programming. In particular, this is a b

k

that explores the principle ideas

f
b

ject-orien ted programming in the con text

f

the Ja v a programming language. Ob ject-orien ted programming has b een a hot topic for

v

er a decade, and more recen tly Ja v a has b ecome the commonly p erceiv ed em b

dimen

t

f
b

ject-orien ted ideas. This b

k

will help y

u

understand Ja v a. It mak es no pretensions to b eing a language reference man ual; there are man y

ther

b

ks

that fall in to that category . But kno wing the syn tax for a language should not b e confused with an understanding

f

wh y the language has b een dev elop ed in the w a y it has, wh y certain things are done the w a y they are,

r

wh y Ja v a programs lo

k

the w a y they do. This b

k

explores this issue

f

why. Ob ject-orien ted programming is frequen tly referred to as a new programming p ar adigm. The w

rd

paradigm

riginally

mean t example,

r

mo del. F

r

example, a paradigm sen tence w

uld

help y

u

remem b er ho w to conjugate a v erb in a foreign language. More generally , a mo del is an example that helps y

u

understand ho w the w

rld

w

rks.

F

r

example, the Newtonian mo del

f

ph ysics explains wh y apples fall to the ground. In computer science, a paradigm explains ho w the elemen ts that go in to making a computer program are

rganized

and ho w they in teract with eac h

ther.

F

r

this reason the rst step in understanding Ja v a is appreciating the

b

ject-orien ted w

rld

view. 1.1 A W a y

f

Viewing the W

rld

T

illustrate

the ma jor ideas in

b

ject-orien ted programming, let us consider ho w w e migh t go ab

ut

handling a real-w

rld

situation and then ask ho w w e could mak e the computer more closely mo del the tec hniques emplo y ed. Supp

se

I wish to send

w

ers to a friend who liv es in a cit y man y miles a w a y . Let me call m y friend Sally . Because

f

the distance, there is no p

ssibilit

y

f

m y pic king the

w

ers and carrying them to her do

r

m yself. Nev ertheless, sending her the

w

ers is an easy enough task; I merely go do wn to m y lo cal

rist

(who 13

SLIDE 4 14 CHAPTER 1. OBJECT-ORIENTED THINKING ME Flo ra @ @ Sally's Flo rist Wholesaler Flo w er Arranger

E

E E E E E Delivery P erson Sally Gro w er

Ga

rdeners C C Figure 1.1: The comm unit y

f

agen ts helping me happ ens to b e named Flora), tell her the v ariet y and quan tit y

f
w

ers I wish to send and giv e her Sally's address, and I can b e assured the

w

ers will b e deliv ered exp edien tly and automatically . 1.1.1 Agen ts and Comm unities A t the risk

f

b elab

ring

a p

in

t, let me emphasize that the mec hanism I used to solv e m y problem w as to nd an appropriate agent (namely , Flora) and to pass to her a message con taining m y request. It is the r esp

nsibility
f

Flora to satisfy m y request. There is some metho d{some algorithm

r

set

f
p

erations{used b y Flora to do this. I do not need to kno w the particular metho d she will use to satisfy m y request; indeed,

ften

I do not w an t to kno w the details. This information is usually hidden from m y insp ection. If I in v estigated ho w ev er, I migh t disco v er that Flora deliv ers a sligh tly dieren t message to another

rist

in m y friend's cit y . That

rist,

in turn, p erhaps has a sub

rdinate

who mak es the

w

er arrangemen t. The

rist

then passes the

w

ers, along with y et another message, to a deliv ery p erson, and so

n.

Earlier, the

rist

in Sally's cit y had

btained

her

w

ers from a

w

er wholesaler who, in turn, had in teractions with the

w

er gro w ers, eac h

f

whom had to manage a team

f

gardeners. So,

ur

rst

bserv

ation

f
b

ject-orien ted problem solving is that the solution to m y problem required the help

f

man y

ther

individuals (Figure 1.1). Without their help, m y problem could not b e easily solv ed. W e phrase this in a general fashion as the follo wing: An

b

ject

rien

ted program is structured as a c

mmunity
f

in teracting agen ts, called

bje

cts. Eac h

b

ject has a role to pla y . Eac h

b

ject pro vides a service,

r

p erforms an action, that is used b y

ther

mem b ers

f

the comm unit y .

SLIDE 5 1.1. A W A Y OF VIEWING THE W ORLD 15 1.1.2 Messages and Metho ds The c hain reaction that ultimately resulted in the solution to m y program b egan with m y request to Flora. This request lead to

ther

requests, whic h lead to still more requests, un til m y

w

ers ultimately reac hed m y friend. W e see, therefore, that mem b ers

f

this comm unit y in teract with eac h

ther

b y making requests. So,

ur

next principle

f
b

ject-

rien

ted problem solving is the v ehicle b y whic h activities are initiated: Action is initiated in

b

ject-orien ted programming b y the transmission

f

a message to an agen t (an

bje

ct) resp

nsible

for the action. The message enco des the request for an action and is accompanied b y an y additional information (argumen ts) needed to carry

ut

the request. The r e c eiver is the

b

ject to whom the message is sen t. If the receiv er accepts the message, it accepts the resp

nsibilit

y to carry

ut

the indicated action. In resp

nse

to a message, the receiv er will p erform some metho d to satisfy the request. W e ha v e noted the imp

rtan

t principle

f

information hiding in regard to message passing{that is, the clien t sending the request need not kno w the actual means b y whic h the request will b e honored. There is another principle, all to

h

uman, that w e see is implicit in message passing. If there is a task to p erform, the rst though t

f

the clien t is to nd some- b

dy

else he

r

she can ask to do the w

rk.

This second reaction

ften

b ecomes atrophied in man y programmers with extensiv e exp erience in con v en tional tec hniques. F requen tly , a dicult h urdle to

v

ercome is the idea in the programmer's mind that he

r

she m ust write ev erything and not use the services

f
thers.

An imp

rtan

t part

f
b

ject-orien ted programming is the dev elopmen t

f

reusable comp

nen

ts, and an imp

rtan

t rst step in the use

f

reusable comp

nen

ts is a willingness to trust soft w are written b y

thers.

Information hiding is also an imp

rtan

t asp ect

f

programming in con v en tional languages. In what sense is a message dieren t from, sa y , a pro cedure call? In b

th

cases, there is a set

f

w ell-dened steps that will b e initiated follo wing the request. But, there are t w

imp
rtan

t distinctions. The rst is that in a message there is a designated r e c eiver for that message; the receiv er is some

b

ject to whic h the message is sen t. In a pro cedure call, there is no designated receiv er. The second is that the interpr etation

f

the message (that is, the metho d used to resp

nd

to the message) is dep enden t

n

the receiv er and can v ary with dieren t receiv ers. I can giv e a message to m y wife Elizab eth, for example, and she will understand it and a satisfactory

utcome

will b e pro duced (that is,

w

ers will b e deliv ered to m y friend). Ho w ev er, the metho d Elizab eth uses to satisfy the request (in all lik eliho

d,

simply passing the request

n

to Flora) will b e dieren t from that used b y Flora in resp

nse

to the same request. If I ask Kenneth, m y den tist, to send

w

ers to m y friend, he ma y not ha v e a metho d for solving that problem. If he understands the request at all, he will probably issue an appropriate error diagnostic.

SLIDE 6 16 CHAPTER 1. OBJECT-ORIENTED THINKING Let us mo v e

ur

discussion bac k to the lev el

f

computers and programs. There, the distinction b et w een message passing and pro cedure calling is that, in message passing, there is a designated receiv er, and the in terpretation{the selection

f

a metho d to execute in resp

nse

to the message{ma y v ary with dieren t receiv ers. Usually , the sp ecic receiv er for an y giv en message will not b e kno wn un til run time, so the determination

f

whic h metho d to in v

k

e cannot b e made un til then. Th us, w e sa y there is late binding b et w een the message (function

r

pro cedure name) and the co de fragmen t (metho d) used to resp

nd

to the message. This situation is in con trast to the v ery early (compile-time

r

link-time) binding

f

name to co de fragmen t in con v en tional pro cedure calls. 1.1.3 Resp

nsibilities

A fundamen tal concept in

b

ject-orien ted programming is to describ e b eha vior in terms

f

r esp

nsibilities.

My request for action indicates

nly

the desired

utcome

(o w ers for m y friend). Flora is free to pursue an y tec hnique that ac hiev es the desired

b

jectiv e and is not hamp ered b y in terference

n

m y part. By discussing a problem in terms

f

resp

nsibilities

w e increase the lev el

f

abstraction. This p ermits greater indep endenc e b et w een

b

jects, a critical factor in solving complex problems. The en tire collection

f

resp

nsibilities

asso ciated with an

b

ject is

ften

describ ed b y the term pr

to

c

l.

A traditional program

ften
p

erates b y acting

n

data structures, for example c hang- ing elds in an arra y

r

record. In con trast, an

b

ject

rien

ted program r e quests data structures (that is,

b

jects) to p erform a service. This dierence b et w een viewing soft w are in traditional, structured terms and viewing it from an

b

ject-orien ted p ersp ectiv e can b e summarized b y a t wist

n

a w ell-kno wn quote: Ask not what y

u

can do to y

ur

data structures, but rather ask what y

ur

data structures can do for y

u.

1.1.4 Classes and Instances Although I ha v e

nly

dealt with Flora a few times, I ha v e a rough idea

f

the b eha vior I can exp ect when I go in to her shop and presen t her with m y request. I am able to mak e certain assumptions b ecause I ha v e information ab

ut
rists

in general, and I exp ect that Flora, b eing an instance

f

this category , will t the general pattern. W e can use the term Flo rist to represen t the category (or class)

f

all

rists.

Let us incorp

rate

these notions in to

ur

next principle

f
b

ject-orien ted programming: All

b

jects are instanc es

f

a class. The metho d in v

k

ed b y an

b

ject in resp

nse

to a message is determined b y the class

f

the receiv er. All

b

jects

f

a giv en class use the same metho d in resp

nse

to similar messages.

SLIDE 7 1.1. A W A Y OF VIEWING THE W ORLD 17 ' & $ % Material Object ' & $ % Animal ' & $ % Mammal ' & $ % Human ' & $ % Shopk eep er ' & $ % Flo rist Flor a Figure 1.2: { The categories surrounding Flora. 1.1.5 Class Hierarc hies{Inheritance I ha v e more information ab

ut

Flora{not necessarily b ecause she is a

rist

but b ecause she is a shopk eep er. I kno w, for example, that I probably will b e ask ed for money as part

f

the transaction, and that in return for pa ymen t I will b e giv en a receipt. These actions are true

f

gro cers, stationers, and

ther

shopk eep ers. Since the category Flo rist is a more sp ecialized form

f

the category Shopk eep er, an y kno wledge I ha v e

f

Shopk eep ers is also true

f

Flo rists and hence

f

Flora. One w a y to think ab

ut

ho w I ha v e

rganized

m y kno wledge

f

Flora is in terms

f

a hierarc h y

f

categories (see Figure 1.2). Flora is a Flo rist, but Flo rist is a sp ecialized form

f

Shopk eep er. F urthermore, a Shopk eep er is also a Human; so I kno w, for example, that Flora is probably bip edal. A Human is a Mammal (therefore they n urse their y

ung

and ha v e hair), and a Mammal is an Animal (therefore it breathes

xygen),

and an Animal is a

SLIDE 8 18 CHAPTER 1. OBJECT-ORIENTED THINKING Material Objects

Animal

Plant Mammal Flo w er Dog Human Plat ypus H H H H H H H H H H H H Shopk eep er Artist Dentist

@

@ @ @ X X X X X X X X X X X X X X Ca rnation

B

B B B H H H H H H H Flo rist P

tter

Flash Flor a Elizab eth Kenneth Phyl Sal ly's

wers

Figure 1.3: { A class hierarc h y for v arious material

b

jects. Material Object (therefore it has mass and w eigh t). Th us, quite a lot

f

kno wledge that I ha v e that is applicable to Flora is not directly asso ciated with her,

r

ev en with her category Flo rist. The principle that kno wledge

f

a more general category is also applicable to a more sp ecic category is called inheritanc e. W e sa y that the class Flo rist will inherit attributes

f

the class (or category) Shopk eep er. There is an alternativ e graphical tec hnique

ften

used to illustrate this relationship, particularly when there are man y individuals with diering lineage's. This tec hnique sho ws classes listed in a hierarc hical tree-lik e structure, with more abstract classes (suc h as Material Object

r

Animal) listed near the top

f

the tree, and more sp ecic classes, and nally individuals, are listed near the b

ttom.

Figure 1.3 sho ws this class hierarc h y for Flora. This

SLIDE 9 1.1. A W A Y OF VIEWING THE W ORLD 19 same hierarc h y also includes Elizab eth, m y dog Flash, Ph yl the plat ypus who liv es at the zo

,

and the

w

ers I am sending to m y friend. Information that I p

ssess

ab

ut

Flora b ecause she is an instance

f

class Human is also applicable to m y wife Elizab eth, for example. Information that I ha v e ab

ut

her b ecause she is a Mammal is applicable to Flash as w ell. Information ab

ut

all mem b ers

f

Material Object is equally applicable to Flora and to her

w

ers. W e capture this in the idea

f

inheritance: Classes can b e

rganized

in to a hierarc hical inheritanc e structure. A child class (or sub class) will inherit attributes from a p ar ent class higher in the tree. An abstr act p ar ent class is a class (suc h as Mammal) for whic h there are no direct instances; it is used

nly

to create sub classes. 1.1.6 Metho d Binding, Ov erriding, and Exceptions Ph yl the plat ypus presen ts a problem for

ur

simple

rganizing

structure. I kno w that mammals giv e birth to liv e c hildren, and Ph yl is certainly a Mammal, y et Ph yl (or rather his mate Ph yllis) la ys eggs. T

accommo

date this, w e need to nd a tec hnique to enco de exc eptions to a general rule. W e do this b y decreeing that information con tained in a sub class can

verride

information inherited from a paren t class. Most

ften,

implemen tations

f

this approac h tak es the form

f

a metho d in a sub class ha ving the same name as a metho d in the paren t class, com bined with a rule for ho w the searc h for a metho d to matc h a sp ecic message is conducted: The searc h for a metho d to in v

k

e in resp

nse

to a giv en message b egins with the class

f

the receiv er. If no appropriate metho d is found, the searc h is conducted in the p ar ent class

f

this class. The searc h con tin ues up the paren t class c hain un til either a metho d is found

r

the paren t class c hain 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 hierarc h y , the metho d executed is said to

verride

the inherited b eha vior. Ev en if the compiler cannot determine whic h metho d will b e in v

k

ed at run time, in man y

b

ject-orien ted languages, suc h as Ja v a, 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. That m y wife Elizab eth and m y

rist

Flora will resp

nd

to m y message b y dieren t metho ds is an example

f
ne

form

f

p

lymorphism.

W e will discuss this imp

rtan

t part

f
b

ject-orien ted programming in Chapter 12. As explained, that I do not, and need not, kno w exactly what metho d Flora will use to honor m y message is an example

f

information hiding.

SLIDE 10 20 CHAPTER 1. OBJECT-ORIENTED THINKING 1.1.7 Summary

f

Ob ject-Orien ted Concepts Alan Ka y , considered b y some to b e the father

f
b

ject-orien ted programming, iden tied the follo wing c haracteristics as fundamen tal to OOP [Ka y 1993 ]: 1. Ev erything is an

bje

ct. 2. Computation is p erformed b y

b

jects comm unicating with eac h

ther,

requesting that

ther
b

jects p erform actions. Ob jects comm unicate b y sending and receiving messages. A message is a request for action bundled with whatev er argumen ts ma y b e necessary to complete the task. 3. Eac h

b

ject has its

wn

memory, whic h consists

f
ther
b

jects. 4. Ev ery

b

ject is an instanc e

f

a class. A class simply represen ts a grouping

f

similar

b

jects, suc h as in tegers

r

lists. 5. The class is the rep

sitory

for b ehavior asso ciated with an

b

ject. That is, all

b

jects that are instances

f

the same class can p erform the same actions. 6. Classes are

rganized

in to a singly ro

ted

tree structure, called the inheritanc e hier- ar chy. Memory and b eha vior asso ciated with instances

f

a class are automatically a v ailable to an y class asso ciated with a descendan t in this tree structure. 1.2 Computation as Sim ulation The view

f

programming represen ted b y the example

f

sending

w

ers to m y friend is v ery dieren t from the con v en tional conception

f

a computer. The traditional mo del describing the b eha vior

f

a computer executing a program is a pr

c

ess-state

r

pige

n-hole

mo del. In this view, the computer is a data manager, follo wing some pattern

f

instructions, w andering through memory , pulling v alues

ut
f

v arious slots (memory addresses), transforming them in some manner, and pushing the results bac k in to

ther

slots (see Figure 1.4). By examining the v alues in the slots, w e can determine the state

f

the mac hine

r

the results pro duced b y a computation. Although this mo del ma y b e a more

r

less accurate picture

f

what tak es place inside a computer, it do es little to help us understand ho w to solv e problems using the computer, and it is certainly not the w a y most p eople (pigeon handlers and p

stal

w

rk

ers excepted) go ab

ut

solving problems. In con trast, in the

b

ject-orien ted framew

rk

w e nev er men tion memory addresses, v ari- ables, assignmen ts,

r

an y

f

the con v en tional programming terms. Instead, w e sp eak

f
b

jects, messages, and resp

nsibilit

y for some action. In Dan Ingalls's memorable phrase: Instead

f

a bit-grinding pro cessor...plundering data structures, w e ha v e a uni- v erse

f

w ell-b eha v ed

b

jects that courteously ask eac h

ther

to carry

ut

their v arious desires [Ingalls 1981 ].

SLIDE 11 1.2. COMPUT A TION AS SIMULA TION 21 "! #

"!

#

a[1]:

a[2]: a[3]: a[4]: 4 6 2 4 x: 47 i: j: 2 3 Figure 1.4: { Visualization

f

imp erativ e programming. Another author has describ ed

b

ject-orien ted programming as \animistic": a pro cess

f

creating a host

f

help ers that form a comm unit y and assist the programmer in the solution

f

a problem [Actor 1987 ]. This view

f

programming as creating a \univ erse" is in man y w a ys similar to a st yle

f

computer sim ulation called \discrete ev en t-driv en sim ulation." In brief, in a discrete ev en t-driv en sim ulation the user creates computer mo dels

f

the v arious elemen ts

f

the sim ulation, describ es ho w they will in teract with

ne

another, and sets them mo ving. This is almost iden tical to the a v erage

b

ject-orien ted program, in whic h the user describ es what the v arious en tities in the univ erse for the program are, and ho w they will in teract with

ne

another, and nally sets them in motion. Th us, in

b

ject-orien ted programming, w e ha v e the view that c

mputation

is simulation [Ka y 1977 ]. 1.2.1 The P

w

er

f

Metaphor An easily

v

erlo

k

ed b enet to the use

f
b

ject-orien ted tec hniques is the p

w

er

f

metaphor. When programmers think ab

ut

problems in terms

f

b eha viors and resp

nsibilities
f
b-

jects, they bring with them a w ealth

f

in tuition, ideas, and understanding from their ev- eryda y exp erience. When en visioned as pigeon holes, mailb

xes,
r

slots con taining v alues, there is little in the programmer's bac kground to pro vide insigh t in to ho w problems should b e structured. Although an throp

morphic

descriptions suc h as the quote b y Ingalls ma y strik e some p eople as

dd,

in fact they are a reection

f

the great exp

sitiv

e p

w

er

f

metaphor. Journalists mak e use

f

metaphor ev ery da y , as in the follo wing description

f
b

ject-orien ted programming from Newswe ek:

SLIDE 12 22 CHAPTER 1. OBJECT-ORIENTED THINKING Unlik e the usual programming metho d{writing soft w are

ne

line at a time{ NeXT's \ob ject-orien ted" system

ers

larger building blo c ks that dev elop ers can quic kly assem ble the w a y a kid builds faces

n

Mr. P

tato

Head. P

ssibly

it is this p

w

er

f

metaphor, more than an y

ther

feature, that is resp

nsible

for the frequen t

bserv

ation that it is

ften

easier to teac h

b

ject-orien ted programming concepts to computer no vices than to computer professionals. No vice users quic kly adapt the metaphors with whic h they are already comfortable from their ev eryda y life, whereas seasoned computer professionals are blinded b y an adherence to more traditional w a ys

f

viewing computation. As y

u

start to examine the Ja v a programs presen ted in the b

k,

as w ell as creating y

ur
wn

Ja v a programs, y

u

ma y nd it useful to en vision the pro cess

f

programming as similar to the task

f

\training" a univ erse

f

agen ts to in teract smo

thly

with eac h

ther,

eac h pro viding a certain small and w ell dened service to the

thers,

eac h con tributing to the eectiv e execution

f

the whole. Think ab

ut

ho w y

u

ha v e

rganized

comm unities

f

individuals, suc h as a club

r

committee. Eac h mem b er

f

the group is giv en certain resp

nsibilities,

and the ac hiv emen t

f

the goals for the

rganization

dep end up

n

eac h mem b er fullling their role. 1.3 Chapter Summary

Ob

ject-orien ted programming is not simply a few new features added to programming languages. Rather, it is a new w a y

f

thinking ab

ut

the pro cess

f

decomp

sing

problems and dev eloping programming solutions.

Ob

ject-orien ted programming views a program as a collection

f

lo

sely

connected agen ts, termed

bje

cts. Eac h

b

ject is resp

nsible

for sp ecic tasks. It is b y the in teraction

f
b

jects that computation pro ceeds. In a certain sense, therefore, programming is nothing more

r

less than the sim ulation

f

a mo del univ erse.

An
b

ject is an encapsulation

f

state (data v alues) and b ehavior (op erations). Th us, an

b

ject is in man y w a ys similar to a mo dule

r

an abstract data t yp e.

The

b eha vior

f
b

jects is dictated b y the

b

ject class. Ev ery

b

ject is an instance

f

some class. All instances

f

the same class will b eha v e in a similar fashion (that is, in v

k

e the same metho d) in resp

nse

to a similar request.

An
b

ject will exhibit its b eha vior b y in v

king

a metho d (similar to executing a pro cedure) in resp

nse

to a message. The in terpretation

f

the message (that is, the sp ecic metho d used) is decided b y the

b

ject and ma y dier from

ne

class

f
b

jects to another.

SLIDE 13 F urther Reading 23

Ob

jects and classes extend the concept

f

abstract data t yp es b y adding the notion

f

inheritanc e. Classes can b e

rganized

in to a hierarc hical inheritance tree. Data and b eha vior asso ciated with classes higher in the tree can also b e accessed and used b y classes lo w er in the tree. Suc h classes are said to inherit their b eha vior from the paren t classes.

Designing

an

b

ject

rien

ted program is lik e

rganizing

a comm unit y

f

individuals. Eac h mem b er

f

the comm unit y is giv en certain resp

nsibilities.

The ac hiv emen t

f

the goals for the comm unit y as a whole come ab

ut

through the w

rk
f

eac h mem b er, and the in teractions

f

mem b ers with eac h

ther.
By

reducing the in terdep endency among soft w are comp

nen

ts,

b

ject-orien ted programming p ermits the dev elopmen t

f

reusable soft w are systems. Suc h comp

nen

ts can b e created and tested as indep enden t units, in isolation from

ther

p

rtions
f

a soft w are application.

Reusable

soft w are comp

nen

ts p ermit the programmer to deal with problems

n

a higher lev el

f

abstraction. W e can dene and manipulate

b

jects simply in terms

f

the messages they understand and a description

f

the tasks they p erform, ignoring implemen tation details. F urther Reading I said at the b eginning

f

the c hapter that this is not a reference man ual. The reference man ual written b y the dev elop ers

f

the language is [Gosling 96 ]. But p erhaps ev en more useful for most programmers is the annotated description

f

the Ja v a class library presen ted b y [Chan 96 ]. Information

n

the in ternal w

rkings
f

the Ja v a system is presen ted b y [Lindholm 97 ]. I noted earlier that man y consider Alan Ka y to b e the father

f
b

ject-orien ted programming. Lik e most simple assertions, this

ne

is

nly

somewhat supp

rtable.

Ka y himself [Ka y 1993 ] traces m uc h

f

the inuence

n

his dev elopmen t

f

Smalltalk to the earlier computer programming language Sim ula, dev elop ed in Scandina via in the early 1960s [Dahl 1966 ]. A more accurate history w

uld

b e that most

f

the principles

f
b

ject-

rien

ted programming w ere fully w

rk

ed

ut

b y the dev elop ers

f

Sim ula, but that these w

uld

ha v e b een largely ignored b y the profession had they not b een redisco v ered b y Ka y in the creation

f

the Smalltalk programming language. I will discuss the history

f

OOP in more detail in the next c hapter. Lik e most terms that ha v e found their w a y in to the p

pular

jargon,

bje

ct-oriente d is used more

ften

than it is dened. Th us, the question What is

b

ject-orien ted programming? is surprisingly dicult to answ er. Bjarne Stroustrup has quipp ed that man y argumen ts app ear to b

il

do wn to the follo wing syllogism:

X

is go

d.

SLIDE 14 24 CHAPTER 1. OBJECT-ORIENTED THINKING

Ob

ject-orien ted is go

d.
Er

go, X is

b

ject-orien ted [Stroustrup 1988 ]. Roger King argued [Kim 1989 ], that his cat is

b

ject-orien ted. After all, a cat exhibits c har- acteristic b eha vior, resp

nds

to messages, is heir to a long tradition

f

inherited resp

nses,

and manages its

wn

quite indep enden t in ternal state. Man y authors ha v e tried to pro vide a precise description

f

the prop erties a programming language m ust p

ssess

to b e called

bje

ct-oriente d. I m yself ha v e written an earlier b

k

([Budd 97 ]) that tries to explain

b

ject-orien ted concepts in a language-indep en t fashion. See also, for example, the analysis b y Josephine Micallef [Micallef 1988 ],

r

P eter W egner [W egner 1986 ]. W egner, distinguishes

bje

ct-b ase d languages, whic h supp

rt
nly

abstraction (suc h as Ada), from

bje

ct-oriente d languages, whic h m ust also supp

rt

inheritance. Other authors{notably Brad Co x [Co x 1990 ]{dene the term m uc h more broadly . T

Co

x,

b

ject-orien ted programming represen ts the

bje

ctive

f

programming b y assem bling solutions from collections

f
-the-shelf

sub comp

nen

ts, rather than an y particular te ch- nolo gy w e ma y use to ac hiev e this

b

jectiv e. Rather than dra wing lines that are divisiv e, w e should em brace an y and all means that sho w promise in leading to a new soft w are Industrial Rev

lution.

Co x's b

k
n

OOP [Co x 1986 ], although written early in the dev elopmen t

f
b

ject-orien ted programming and no w somewhat dated in details, is nev ertheless

ne
f

the most readable manifestos

f

the

b

ject-orien ted mo v emen t. Study Questions 1. What is the

riginal

meaning

f

the w

rd

paradigm? 2. Ho w do

b

jects in teract with eac h

ther?

3. Ho w are messages dieren t from pro cedure calls? 4. What is the name applied to describ e an algorithm an

b

ject uses to resp

nd

to a request? 5. Wh y do es the

b

ject-orien ted approac h naturally imply a high degree

f

information hiding? 6. What is a class? Ho w are classes link ed to b eha vior? 7. What is a class inheritance hierarc h y? Ho w is it link ed to classes and b eha vior? 8. What do es it mean for

ne

metho d to

v

erride another metho d from a paren t class? 9. What are the basic elemen ts

f

the pro cess-state mo del

f

computation?

SLIDE 15 F urther Reading 25 10. Ho w do es the

b

ject-orien ted mo del

f

computation dier from the pro cess-state mo del? 11. In what w a y is a

b

ject

rien

ted program lik e a sim ulation? Exercises 1. In an

b

ject-orien ted inheritance hierarc h y , eac h lev el is a more sp ecialized form

f

the preceding lev el. Giv e an example

f

a hierarc h y found in ev eryda y life that has this prop ert y . Some t yp es

f

hierarc h y found in ev eryda y life are not inheritance hierarc hies. Giv e an example

f

a hierarc h y that is not an inheritance hierarc h y . 2. Lo

k

up the denition

f

p ar adigm in at least three dictionaries. Relate these deni- tions to computer programming languages. 3. T ak e a real-w

rld

problem, suc h as the task

f

sending

w

ers describ ed earlier, and describ e its solution in terms

f

agen ts (ob jects) and resp

nsibilities.

4. Consider an

b

ject in the real w

rld,

suc h as a p et animal. Describ e some

f

the classes,

r

categories, to whic h the

b

ject b elongs. Can y

u
rganize

these categories in to an inheritance hierarc h y? What kno wledge concerning the

b

ject is represen ted in eac h category? 5. If y

u

are familiar with t w

r

more distinct computer programming languages, giv e an example

f

a problem sho wing ho w

ne

language w

uld

direct the programmer to

ne

t yp e

f

solution, and a dieren t language w

uld

encourage an alternativ e solution. 6. Argue either for

r

against the p

sition

that computing is basically sim ulation. (Y

u

ma y w an t to read the article b y Alan Ka y in Scientic A meric an [Ka y 1977 ].)