Open Issues in Object-Oriented Programming: Learning Methods, Object Decomposition and Inheritance and Reuse

TR93-016

John Hilgedick

The University of Nonh Carol ina at Chapel Hill Department o f Compmer Science CB#317.5. Sinerson Hall Chapel Hil l, NC 27599-.>175 9 J 9-962-1792 jbs@cs.unc.edu

A TexlLab/Collaboratory Report

Portions of th is work were supponed by the National Science Found arion (Gran t #!Rf-9015443 and by IBM Corporauon rSUR Agreement #866).

UNC is an Equal Opponunity/Affim1ative A(.:tion lnstirution.

JO!-IJ'-: MA TTl-lEW HILGEDICK. Open Issues in Object-Oriented Programming:

t eaming Methods. Obje<.cr Decompo>idon. ;llld l nheriwnce and Reuse (Under the

d irection of Dr. John B. Smi th)

ABSTRACT

This thesis prcsenL~ a ~urvcy of the li rcr:uure of three open issues in object-oriented

progmn1n1ing:

I. Lc:u11 ing 'VIet hods. The dift!cullics that beginners face in object-oriented

programming are Stillllllarized. Technique' tor sunnouming these problems are

presented.

2. Object Decomposition. Decomposi rion rechniques for absrracring and

representi ng a problem domain are placed wi thin four categories accord ing to

their method of object fom1ation. The effectiveness of rhe techniques are

compared and concrasted.

3. l nherimnce ~nd Reuse. Forms of ret1se are idenrified. Object-oriented

mechanisms for obtaining code reuse are pre>emed. I nheritance is shown to be

difficult to use effenively. Advanwgcs and disadvantages of single and

multip le inherit:111ce :u·e di>cusscd.

II

ACKNOWLEDGi\lENTS

l wish to thank a number of i ndividuals who have given their time, effort, and

support in making this thesis possible.

l would like to thank Dr. John B. Smith for his guidance in such a difficult ta>k

•tnd for his years of support during my graduate career.

l wish to ;rcknowledge the hel pful cri1icism of Dr. James M. Coggins.

~especiall y regarding the m:aerial on inheritance and reuse.

r would also l ike to thank Dr. Susann:t Schwab for her support and comments

in the prepar;uion of ;h is document.

l gratefully acknowledge my parems. :-.lanl'v. John, Don. and Elaine. for the ir

encouragement and suppon of my manv qu.:sts.

Most imponantlv. I wish to thank my be~t friend and wife, Elizabeth, for her

years of support. kindness. devotion. and terwc!ty r:~s wel l as her wonderful editing

job). I'm a bcucr persr>n because (lf h~r.

iii

TABLE OF CO.' HEi'\TS

List of Figures . .. ... .. .. . .. ....... . .......... . .......... , .. .... ............. ......... ... . ... . ...... vi

lnrroducrion ... . . ......... ............ .. ................ . ....... . ...... .... . ... ................ . .... I A Brief History of O~ject·Oriemcd Programming ... .. .. ... .. . .. .. ... ... ..... .. .... ...... 2 Vocabulary ....... ....... ...... . .. ... .. . .... ... .. .. .... . .... . .. .... .......................... ... ~

Chapter 1: L~aming :VIeth<Xis ........... . .. ... .... ..... .. ................... ... ........ ........ . . 6 Relinquishing Process-Oriented Thinking . .. ... .... ....................................... 6 Confusion Between Object~ and Classes . .. .. . .. .. .......... .. .... . .. ........... .. ........ ~ Encapsulatio n .. .. .. . ... .. . .. . .. .. ... . ... .. ..... .... ... .... . ...... .. ... ........... ... ....... .. . l:< Message Passing .... ....... . ...... .. .. ...... .. , .. . .. .. .. ........ ..... .. ............... ... .... II Object Decomposition .. .. ..... ............. ........ ...... ... .... .... .. .. ........ .... .. ... .... II Inheritance . ....... ..... . ... . ............. ... .... . .. . . .. ........... .... ... .. .. .... .. ..... . .. .... 1.:1

Chapter 2: Object Decomposition .. .. .... ..... .... .... .... .... ... ........ .... .. ....... .... ... .... 17 Definitions . ... .................... . .......... ... ........ .... .... ..... .. ........... .. .. .... . .... I R Guidelines for the Evaluation and Dev·elopmem of Object Decomposition ........ .... 18

Evaluation of Object Decomposition .. ........ ........................... ... .... .. ..... 18 Development of Good Object Decomposition ............................. ........ .... 19

Methods Available for Object Decomposition .. ... .. . .... ... ......... .... ....... .. .. ... ... 20 Guideline Methods . .. .. .. . ....... . ....... ...... . ...... .................. ... ..... .. ...... 20

Object Oriented Analysis .. . ...... .... .... ... ................... .. ... , . .. .. ..... .. ... 20 lnfonnation Modeling ...... .. ...... .. ....... .. ............... ................... ... 23

Texr Analysis Methods .. . ............. .. . ... ... .. .. .... .... .. .... ....... . .. ..... . ....... 25 Responsibil ity-Driven Method~ ..... .. .. ........ ............... .... ................. ... 27

Responsibi lity·Driven Design .... ..... .. ... . .. . .. ...................... .... . ...... 27 C::RC Cards ...... . .. ........... . ...... .... .. ..... . .... .. ..... . .. ...... . .. .. .. . ........ 29 P!ay Acting .... ... ..... .. ....... .. ............... . ....... .. .. .......... .. ..... ... ... . . 30

Structured Analysis Extraction Methods .... ......... .... .. ............. ... ............ 31 Objecr Oriemed Requiremems Sptcification ........ ..... ..... ............ .. . .. ... 3l Abst raction Analysis ......... ........ ........... .... ... ... .... ..... .... .. .. .. .... 33 Object Oriented StniClurcd Design .. .. .. ... .. .. ... ...... . ............. .. , .. ...... .. 33

Ylodified Structured versus Object-Oriented -\naly>is ;md Design ........ .............. _;5

Chapter 3: Inheritance and Reuse .. ... .......... .... .. .. .. .. .. .... .. ...... ... ...... .. ..... ..... ... 38 Reuse ................ . ........ ............ .. ... . .. .. . .. ... .. ... ...... .......... .. . ...... ... .... 38

Reuse of Code . .. .... . .. . ....... . ... _....... . ......... .. ................ ........ ..... 39 Object-Oriented Mechanisms f(lf Code Ret,~c ...... ...... ......... ... ..... ..... ..... ...... . W

Delegarion .......... . ...... . ..... . ... ........ ...... .... ... ...... ........ ... .......... ...... 39 Genericity.... .. .. .. . .. . .. . . .. . .. . .. . . . . .... . .. .. .. . .. .. ........ ... .. .. ... . .... ....... ... -10 Confonnance and Enhancemem.. . .. .. . .. ........ ....... . ............ .. ...... .... -10 In h~er i t:.tnc;;: .. ... ........... .... ........... .... .... .. ....... . .... ...................... . ..... -10

Why Inheritance is Difficult ......... . .. . .. ............ .. ... .. .... .. .............. . .... ...... -II IHJtil::quace Suppun l'or lnheritamx by Objen Det:<.lmposirion Merhods ........... -ll The Conflict Between lnho::ritan<:e for Defininon and Inheritance for Reuse . . ........... .. .............. .... . .. .. .. ....... ........ ................... ..... ..... .. -12 The C..onflict Between Inheritance and Data Hiding ....... .. ............... .. ....... . -13 Tho:: Contlicr Between Gencra!izauon ami Specialization ... . ...... .. . .... .... ....... -14 Issues Orthogonal 10 Object Ori~nted Programming .. ... .. . .. .. .. . .. .. . ......... . ... -15

Description of Inheritance. Hierarchio::s .. ......................... .. .. .. ..... ............... -16 Advantages and Disadvantages or !nhcrit:mce Hier:1rchy Types .... . ... ...... ... . .. . . .. -16

\ '

Single lnheriwnce/Single Tree .. ... .. .. .. . ..... ... .... .. .... . ... ......... .... ... .. . ... . . 46 Singk lnh.:riwnce/Muhiple T1·ee .. ... .... ... .. ......... ......... ........ . .... .... . ..... . 4~ Multiple lnheritanct: . ... .... .. .... . .. ... ........... ......... . ............................ . 49

C I . . - ~ one us1on . ........ .. ..... .. ..... .. .. ................ . ... ... .. .... ... ......... ......... .... .. ...... :l. The Future of S1ru<:1ured and Obj ect·Orienled Programming ...... ............. ......... 54

Bihliographv....... .. . .. .. ... .... ...... ........ .... . ..... . . ......... .... .. . . .. ... . ............... :06

,.,

LIST OF FIGL:RES

Figure l. l: Pan-of versus Is-a Relationships ... .. .. ........ . ....... .. ................... ..... . 14

Figure 2.1 : Object Oriented A nalysis Diagram~ ... .. .. . .. .... .. .. .. .. .......... . ......... ... .. 21

Figure 2.2: Jnfom1ation Slructurc Destgn .. ~· ... .. .. . .. .. .. .. .. . .. ~- .... .. ...... .. .. .... .... .. . 15

Figure 2.3: Overview lnfomwion Strucwre Design ... .... .. .. ... ... ... .. ....... .. ...... .... . :::S

Figure 2.4: CRC Card, .. .. .. . .. .. ..... .. .. ..... .. .... . .. .. .. .... . ., .... ... ... .. .. ..... . .. ..... 29

Figure 2.5: Obj~c:t Oriented Structurctl D<.:>ign . .. , ........ .. .... . ............. . .. .. ... .. ....... >4

Figure 3. l: Types of Inheritance .. ........ .. .. .... .... ...... .. ..... . .... .. ... ... .. .. ..... .. .... . -17

Figure 3.2: Multip le Inheritance . ... ..... .. . ..... .. ..... .... .. .... . ... .. .. ..... ... .. .. . ..... .. .. . :'\0

l~TRODL'CTlON

With the udvent of ohject-oriemed lang uage~ has come the need to teach or

retrai n those who hope to use them. T here is much disagreement over how this should

be done. Additionally. most technique$ are unecdo;al innmure and their effectiveness

is unknown. Tdemifying the prohlems that novices encoumer is necessary if effecuve

and formal strategies for teaching the principles of objec t-oriented programming are to

be developed. Chapter One summatizes rJ1e most difficult problems beginners face in

object-or iented programming and reviews techn iques for ~urmounting these difficulties.

It al so provide'S a time frame for employing the tedmiqucs.

Chapter Two examines the t~sk of nhj<::cl decomposition. Object decomposition

is the process of examining a problem d0main. ab~tracting the entities that interact

within that dom;1in. nnd detennini ng how best ro encode !hose abstractions. T he

considemble advantage~ of high qu:1l ity obj.:c1 d"eomposirion warrant an in-dep1h look

at this task. A number 0f techniques thm have been used with a higher rate o f success

are presented and cont rasted. The decornposnion techn iques are shown to be lacking in

fonna!iry of rransfomlation and expression.

Chapter T hree examines different types or r<!use and the <)hjecr-onenred

mechanisms for obtaining code reuse and the.n examin~:s inhelirance in greater detail.

Inheritance is >hown t(> he difficult to use h.:c:tt~>t: ,,f a number or· conflicts, including

the -:ontl ict between inheritance and .:ncapsul:nion. betw<::en inht!riti ng for defini tion .md

reuse. and between spec ial iz:u ion and gener:dization. The chapter closes wi th an

examination of the advantagt:s and disadvantages of single and multiple inheritance.

The conc lusion summarizes iswc,; of p:m i('u lar import:tnce to the future of

c>bject-oriemed programming. These isst~es demand fttnher auention (and resolution 1 if

vbjt:ct-oriem<::d programming is tV deliver vn ;he promises that its proponems have

made. lr closes with a brief v1ew of what the fill me may hold for both structured and

obJect-onentcd progra1nt1)Jng.

In rhe rema inder of rhis ~<:<.:don, a bnef ht:<tory of object-oriented programming

is presented to provide cont~ xt t'or discus;;ic on n( th~xe i~suc:s. Addit ionally. key ttrnls

used i n rhe discussion :~ re defined.

A Brief H is1orv of Object-Oric:nt.:d Program min<>

During the 1940s and earl y 1950s. al l programming was performed through 1he

use of machine codes. Typical ly. coding involved the physical setting o f wires or

switches. These " first generation" machine codes forced the user tO think about how

the computer perfom1ed operations. In th~ mid-1950s, a number of " second

generanon" assembly ~'Odes began !O appear. Through the assignment of m.nemonic

names 10 operations. assembly ttxles helped free tht: user frOm 1hinking solely in terms

of wires and switches. In <1 rea .! sense. assembly codes marked the beginning of a

transition from the use of machine language to the development of programming

languages with increasing resemblance to human comm unication.

Although assembly codes offered some freedom for the user, an extensive

knowledge of the computer orch itecmre wa~ still requi red. This prompted the

development or " rhtrd gener'ation" or "high-level" programming languages. A lthough

these Jungu~ges also pluced emphasis on procedu.re and little on data srnrcrure,

languages like FORTRAN. Lisp. Algol. and Cobol allowed the user 10 th ink less about

how computers perfom1ed their operations and more about the operations that were

re4ui red. Cobol c:omributed the concept of the rel'ord dara struc ture. This allowed the

user to define their own data types to augment tho~e predefined in a language. User­

defined dara types gave greater emphasis to th~ description of the data used by the

processes. lL also provided a more effective way to J,rroup re lated data, encouraging

modularity :tnd data hidjng. T his separation of the description of data from the program

'itntemenrs was the beginning of what was to he later known as "data-oriented''

prohrramm1ng.

The i960s and i 97(b saw the dcwlopment M a ilu rry of specialty language:-.

A maJor goal or the developers \lf tht:se language~ was to al low users ro think more

about what they wam~.tl1he computer to do rather than how the computer carried out us

operanons. These languages arc typical ly referred to as "founh generarion" or

declarative languages. One such langu:1ge, Simula. was designed and implemented in

l 962 by Kristen Nygaard and Ole-Johan Dahl 1 Dahl701. Sirnula allowed the userto

>lmul:u e a system by modeling it iL~ :1 set or imer~1ctlve processes. where e:tch process

modded an enrity wuhin the real ,,ystcnl. lri 19(>7. Sitnula67 inrroJuced the concept of

.1 dass as a method of tlesc:ihing a group (>f , jmilar entity abstmcrions. Simula and

Simulu67 funher en<.,ouraged mQdularity by diret:tly :-upporting the grouping of relat~d

dam and procedures. During this sume period. language;, such as Ada and :vtodula-2

pl;rced greater emphasi> on the suppon of modu!e,. The need to support modulari ty

grew •>ut oi a realizatinn that modules genaal l v f<H:i li!ated the decomposi tion of a

problem domain into a set of independent sub-components. maki ng progr:uns easier to

understand and lWl inwin. Modt1 le~ coruribu1cd heavi ly to the creation of abstract data

types.

The first "objec1-oriemed" la11guage was developed in 1971 by Daniel Ingalls.

Ingalls rewrote the software component known as Smal l talk for Alan Kay's Dvnabook

I Goldberg83J. The language was c:ti led ''nbjecl-oriemed" bec:1use it was the first

system to be comple1o;:ly composed of abst:ract dam types instantiated as obje<:.Js. Tht!

inlluence of Smallwlk on the rest of the object-oriented world cannot be

underestimated. T he late 1970s. ! 980s. and earl y 1990s h;ts seen a ban·age of obj ect ­

orienred languages. Flavors [Cannon80. Moon86}. Objective-C [Cox84] . C+-

1 Stroustrup84 J, Eiffel [ :vk)•erSR]. tvfodula--' I C1rdell i921. and Actor I Borkok s90l are

just a few of them.

W ith these languages has come a variety or mechan isms tO suppon the

definition and creation of absmtct daw type~. The most common mechanism is

inherimnce. The abil ity to define abstract data type:; by reusing those previously

defined has introduced a number of difficl!lt and unresolved issues.

For more infonnation. see 1Fricdman91 . S1roustrup88, Shaw84]

Vocahularv

Nlany of the technical tenn s found in the objecL-orien ted programming litermure

are used interchangeably. differently, or erroneously by many aurhors. This i s one of

the first difficulties encoumered by nov1ces whcn attempting to le<Ull the principles oi

object-oriented programming. T his <;ection defines kev rem1s userl th roughout the

remainder of 1his paper.

The tenn proce~s-olierued pco~ramming refer:; ro the ~ryle of programming in

which Lhe processes that make up a probi<:m domain arc the primary componerus to be

abstracted. Additionallv, the tennis frequemlv used to describe the actual encodin£ of "' . ~ .... process abstractions: it is often used imerchJngeablv (and incorrectly) with structured

proh'Tamming. Srructur~d orngramrning refers \O rhe rractice of coding procedures as

block-like structures oi j)rogramrning s!aternems. These ·muemems J:re executed m

sequence, wi th condirion<!l ..:onstrucr~. and withoul gvro , taremems. Objecr oriented

programming refers w the s<yle of programming where the data and their associated

functions are the primttrv emitie, to be absrrac•ed. This :enn i s often used ro describe

the ph ~se o f progr:11m111ng 111 wh ich the actual <!ncnding of entity abstractions i-s

pcrfom1ed.

3

The process of pro•rramming is olten div ided up in to the three somewhat

distinct phases of analysis. design, <tnd implememation. Analv~js involves examining

the problem and irs domain and creating a ser of ab:;rrac!ions w hich adequately

represem !he problem domain. In process-oriented analvsis. emphasis is placed on the

processes that comprise the problen1 domain . In nbjecr-oriented analvsis, the entities

th~t exist, Jntc:ract, ami rcl~uc wuhin the dom:un ~trc ernphas•zed.

The second pha$e or progr:tmnu ng b de.>ign. In design, the set of absrracnon'

thaJ were extracted during the analysis phase are refined into a new set of emities which

are supported by a progJ·amming language. Process oriented design refe rs to the

refinement of process .~bstractions so that they are supported by 3 procedural language.

Object oriented design refer~ to the refinemem of e mity abstractions so thm ihey are

supported by an obj.:<:t-oriL"nted language. Th.; di:-tinction betwcen analysis and dc,ign

can be somewh:u difflt~e and both are frequemlv re ferred 10 as decornpositjon. Process

decompnsition refers tn proc.:ss-oriented analysis and design while nbject

decomposition refers to object-oriented analys1s and design .

The third phase of programming is implementation. This refers to encoding the

process or entity absrracrion~ produced through :uwlysi> and design, in a given

progi'an1n1ing languagl'.

An~ is anything in the rea l world that has both state and behavior.

Examples of entities include people, automnbi les, L"hecking accoums. and the weather.

Upon analysis and design. :111 emity is mapp.ed to a class. A class is an encapsulntion.

or dest·ripdon of a set of em ity almractions. -\ cl:N provides a un iform set of inswnce

variables and methods. including a description of how to ~reate new instances of tht:

class. An in~rance or <'hject is .1 ,ingle inst:HHr<llmn of a class. For a given class. rhere

may be a large number of insranc.cs. The tcm1s objo::ct and instance :tre equivalent.

tl.lthough an object is an insrann: or a class. the 1enn object i~ often mismkenly used

imerchangeably wuh class 111 much of ihe lir~raturc .

Instance variables. Jlso known :1s dara 1ns;mhers or attributes, embody the state

of :m object. These va1i:tbks are c6mnwn to all insmnce> of :1 given ciass. For

example. the clas~ Hou<e might have the auributc :\tunbcrOfRooms. Each insmnee t>t'

da~!; House would h\lVe the inswnce v;:u·iable NurnbcrOfRoon1s and its own private

v3lue for that va riable. :VIethnds, also \..nown as member functions or servic;e~. t.kfinc

the behavior or .tn ohj.:ct. :Vkrhods implemem rkle behaviors common ro :ti l inst3nce' of

a given cla$,. For exampk. rh~ cla~s Frog might h;tvc the method Jump. Each

instance of class Frog woul d ,llare the com111on bdwvior deli ned by the method Jump.

In order for" method "'b.: lllvnkcd. an c>b.tt'l·t mu'1 recelve a me,sa~e. Each method

defined for a class is associat~-'d with a corresponding message. \\-'hen an object

receives a message. i t tn vokes the corresponding method. A message is similar to a

procedure invocat ion. All inrer~tct ion between objects occurs through the passing of

ntessagcs and the subsequent i nvocation of merhods.

The most imponanr comributions o f object-oriented programming are the

~uppon of encapsulati<)fl and inht'rit:lm:e. The principle of encap~ulation requires that

each component of a program must either embody a probkm domain emiry or hide a

single d~si gn decision The unit of encapsulation for most object-oriented languages is

thec13ss. As such. a class encapsulates all smte infonnation and operations necessary

for instances of that clttss. The in terface for each dass is defined to reveal as l iule as

possible about its inner work ing, [ Oxfordi-:61: this is also known as data hiding.

Instances of different cl<tsses may respond differently to identical messages.

This characteristic is known as polvmomhisrn. Fnr example. inswnces of class Car.

Frog, and Planet might all respond to the message :Vtovc but in differem ways because

each type of object associ:nes a different method for that message. This is neces~ary

because the three object~ mtwe di fferently. Inheritance is a mechani~m through which

polymorph i~m can be achieved. IL also simpl ifies the definition of classes similar to

one or more classes pr<::viou~ly defined by "r~us i ng" those class definitions and

augmenting or modify ing them as desired. The teml reuse is f requently assockned with

inheritance since one <::an view the effetr of inhetitance :ts reusing the definition of a

class for the definit ion of nther:<.

The detl ni tion of the,<: concepts :m: fai rlv 'traightforw:~rd. but learning to u~e

them t:ffec!lvely is a <:h:rlkn;!e.

5

Chapter One:

LEAR!'\ ING METHODS

,\fovices encoumer m~ny difficulties when trying to learn object-oriemed

programming. Some diflicuhie~ are conceptual !'uch as reli nquishing process-orienred

thinking and di stinguishing between objects and classes. Other concepnwl difficulti<::s

are re lated to encapsulation. mess<tge passing. ooj¢ct decomp<lsition, and cla.ss

re lat ionships. Additionally, 1here are technical di ftl cu lties a~sociared with many of

these concepts. ~,;Joreover. man)' of the concep!s that underl ie these di fficu lties are

related. making it d iffictdt 10 understand on~ concept with<>ut understanding a num!x:r

of them.

Identifying these difficulties is necessary if effecrive techn iques for learning

object oriemed programming are to be developed. Currently, the techniques for

overcoming these difficulties :u-e anecdotal in nature and fonnal study on their efficacy

is lacking. The sections that follow each describe one of !he difficulties encountered by

novices. Techniques for solving 1hese problems :1nd a lime frame for employing them

Jre presented from a surv.:y nf 1he lirermur~.

Relinquishing Process-Orienred T hinking

Descrinrion. Perhaps the mosr di fficult problem that novice progran1mers face

is shifting focu~ r"rom a process-onemecl to :111 '.:ntity" onenred approach. There JS

disagreement regarding the rela!ionship between ot~ject-oriemed and process-oriented

programming. Some view object-oriemed programming as a revolutionary advance

requning a complete menwl 1:err:uning 1 (leck<''J. Cibson\J II, whi le others view it as a

natural evolution or ex1ension of process-oriented programming requiring only minor

techn ical adju~tmcm> I Wyb<, lt90, Dc~awic•)(l . . \ ·Jon') I] . l)c3pitc tbcsc d itfcrcnccs. It;,

t;iear chat object-oriented programming n:quir~' ,, t!ifft:rent fc>Cus than process·onenced

prn&rr:.u11n1ing.

r n pnx::es;-olienied programmrng. the primary focus is on the processes which

c<,>mprise a problem dom•1in. Passive data are passed back and fon h by processes chat

man·ipuiate rhem. !n order 10 manipulate d:tta pr0tJ<:rly. processes mus1 know the

representation of the data. Processes may interact with m;Jny types of data, therefore a

h'Teat deal of infom1<1rion on the representation of those datl may need to be <~vailable to

tl process. and thus av;tilabte to the programmer or the process.

111 object·orient-:d programming, great.:r <:mphasis is placed on the dma. Instead

of directly manipulating the data, processes ~end requests 10 rhe. data objects which

then. conceptually. 'manipulate rhemse!ve>". A <.:lass. therefore .. includes a user-

deli ned data type and the procedun:s that operate upon i t. Thus. users of a class need

only re4uire knowledge about rhe messages an ohjcct can receive and need never know

the details of the datu represemarion.

The idea that "obje<:ts" know how to mampulace themselves and actively interact

with other objec1s is confusing to manv programmers. Some have labeled th is problem

"relinquishing glohal control thtnkmg" ~ nd believe that it is one or the first and m()sr

difficult concepts 10 be learned I 8<!ck891. Oth<!r:< have argued that i t is so difficult to

overcome, thar individuals with l ittle or no programming experience have less difficulty

in overcoming this problem than more experienced programmers because they have nor

yet become indocrrinated in the proc-'SS·oriented 3pprmtch [McKenna8R f. There is.

however, only anecdotal evidence 10 suppon this l'i:tim.

Potential Solutions. To overcome pro<"eS>·Oricnted thinking. many ex pens

advise a submersion tcchniyue [ Beck89. Gibson91 f. The novice is introduced tO

object-oriented programming concepts through a purely object-oriented langmge like

Smalltalk and allowed to smtggle unti l the concepts are absorbed. It is vinually

impossible to do anything in Smallralk u;ni l some understanding is reached oi manv ,Jf

the basic concepts of object·nriemed prog1·amrning.

Otl!crs argue rhat th is sink-or·<Wm1 technique is both unneees:;ary ~nd

impractical. Ylany complrnies that emplov hl.tge mnnlx:r> of pr()grammers often tind it

more effective to introduc<: ()bjt:ct·uriemed .:onccpts in a more evolutionary, rather than

revolutionary, manner I Wyboh9D, Dei\iamle90. ;\•loo911. ~ovices are intrcxluced to

object-orienred <.:oncepts through a hybrid I:Jnguage ,uch as C.,.+ that supports both

prOCe5s·oriemed and ohj<!cr-.1rbned programming. This allows rhem to gradtrallv

ad()ptthe new ..:oncepl' l)f ,lhject·otienred progr;nnming. Puri~ts argue that thrs

approach is not as effewve Ill u·ansnuuing the necessary understanding ()f basrc

concepts :,rmpiy becau>e th~ user '' not fnrced m con trorl! rhe basic issues of object­

oriemed programm111g. Because hv,l>nd langu:rge~ .II low the user to continue ro

program using structured pro1,'T:rmmrng rech ruque'. i t rs argued that novices have no

reason, or rind it difficult. ro c·ome to grips with rhc cc>n<.:ept~ of object-oriented

programming [ Hender~0n<) I . Gihson<l I . 13edS~i -

7

Still other.; a~s~n that the best way to learn object-oriemed programh1ing is n<H

through the use of a l:wgtmge at aiL They claim that any languag;:, pure or hybrid ,

colors the novice's thinking about what object-oriented programming is and how i t can

best be done. They ~rgue that object-ori.::med programming is nor defined by a

p:micular language but is a way of examining a p roblem. They concluded that language

independent $cUtngs .tre bes1: [0$heali6. Lteheri>en-89!.

Time Frame for Learntn". Most experienced trainers tlt:d rhat perce tving the

difference between processes and ennries in a problem domain, and comprehending the

idea of objects manipulating them;;elves can take from a few weeks to a few months

[:V1eyer93, Whiting931. Of the techniques de,cr ibed above. none has been shown to he

superior in either reg;trd.

Confpsion Betw~~n Ohjects and Cl as~c~

Descripti on. Class and object are two d i~tinct concepts. Novices often rreat

ch1ss and object as interchangeable concepts. In fact. the literature often uses the words

erroneously. This confusion can result in di t'fintl ties understanding o ther concepts of

object-oriented prograll\tning.

Potemial Solutions. When inrroducm!! the concepts of classes and objects. it is often helpful wnh experienced programmer;; to us~ the analogy of types and variables.

The type of a variable provides infomtation to both the user and the compiler abou t the

~tntcwre and behavior nf the v;triable. For ;t gtven type. there may be a number of

msmnces (variables) ot' ;hat type. ~ach followin~; th.: ruk:;; for that type. In objeci­

otiemed programming, a class t> used to desert be the srrucrure and behavior of

instances woject~J t>f I hat cia~!>. For :1 ~iven ·:b''· tJtere may b" a number of instance;,

(objects) o f that cbss. All i tNance~ (ohject~ ) M a ~iven class h~ve the same auributes

and the same methods .. ·\cia;;$. therefore. -:~trt b ~ vicw~u :ts a description of the

attributes and methods an tnsmncc of that class will have.

Time Frame for Leaming. Learning the di-;;inction between class and obj ect

i:; dusive for manv, Di fferem trainers indic:tte that n takes a few momems ro a few

hour.;. Mey.:r believe;; that much or' tile popular literarure is $0 com'using that it con

take month~; t'or ..treader to overcome th i~ prqbie:rn I ~Vleyer9~). C..:nmnly for

experienced pro~ramtnc,s. the.: :tn:t l11g~ abO"<' ' hOi tltl 'honen the lt!aming period.

Enca!)>Uiat ion

DescrjDtion. The encap;ulationof an t'IHHY refers to the combination of state

i nfom1mion needed to ex pres' dte enriry with tht· <'per:uions needed to support that

infonn ation. The mechanisms ror encapsul:11ion are perhaps the most imponant

connibution rhar objec!-OTiemed programming has to offer. Frequentl y , novices have

difficulty understanding whar procedures should be combined with data. and

derennining which classes should com~ in the data.

One function o f encapsulation is 10 isolate modules that i nterne! with an

encapsulated object from obtain ing knowledge atx>ur irs implemenrarion. If knowledge

about an implementation is gained and reli ed upon by other modules and that

implementation changes. then that knowledge becomes invalid and errors resu lr.

When auempting to encapsulate ar1 entity. novices often make three errors.

Frequen1ly. there is a failure 10 properly encapsulate ttl! o f the necessary components oi

an entity, giv ing acce$s to inappropriate i11fonnat i0n. T hese components may ex ist at

varying levels of abstrac tion. A componem may be of a lower level and involve

in;annce variables or method; derined for d1e intemal maintenance of an object. For

example·, a user auempti11g to encapsu lat~ a sta<.:k might implement the stack as-an array,

and provide a method tor updating the stack poim~r. The manipulation of a srack

poi mer is the sole responsibility of the s1ack and no other class should be given access

to such a method. [f such access is allowed. other modules and objec1s may d irec tly

manipu late 1he s1ack pointer and compromise the integri ty of the SHick.

Other design decisions that ca11 be encapsul:ued improperly are of a higher level.

A user might encapsulatt: an entity and improperly disclose the "philosophy" of the

object. Such d isclosure should always be expl icir. Had the user wished 10 d isclose

this infonnation, it mig In be done more properl y by incorporaring it into the ciass name

or by providing a me1hod which returns the desired i nfOnnmion. For example, a user

wishing ro encapsulate a SonedCollection may improperly disclose that the c lass uses a

particu lar algorithm 10 ,on irs mernbe;rs. Another dass. requiring the same algorithm

/possibly bec3use of space or rime l imitations). might employ the SonedCollection to

son i ts members. Because there IS no explicn Indication of the algorithm used by

SonedCollec1ion. other classes may behave unpredictably i f the algorithm is changed ar

~ later !!me .

.'\ third problem ~~ thm n0vices are of1en un,ure how gener~tt or speci tic 10 make

an encap,;u latton. (jener:llizari<'n and special ization arc competing go:ds and finding a

b~tlance is often very di fticult. Objects should he general enough iO be reused in iuture

proJects. but not so generJI :1~ to make their intended use incompn:hensible or

inefficient.

Pmenrjal Solu!ions. Many argue !hat the presemation of object-oriemed

programming a~ an exr~n>inn or L'volullon ,,f rnx·es,-oriented progmmming makes 1hc

concepr of encapsulat ion m1JCh easier to comprehend. Beginning with the principles

underlying the concepr of a module often provides a good rrnnsition point between

process-oriemed and object-oriented programming. In process-orien ted programming,

modules are used ro model processes, but <u·e fre.qucmly used ro model enti ties as well.

Modules were developed in an mrempr to divide large programs into smaller

componems. The use of these smaller componems offers rwo distinct advantages,

parricul<rrly when they ab~rract single design decisions. Fi rst. modules faci litatt:

concepmal understanding. Secondly. moduks c.an be more thoro ugh tested because

they have fewer input values than a system that has not been divided into sub­

components. This maktcs the component easier to test for errors and increases

rel i:tbliity [Dijksrra68].

Parnas offers a number of reasons why the abstraction of data representation is

superior to the abstraction or processes I Pamas72al . He <rrgues that data

represemations are f;u· more l ikely to change than the proces~es that act upon them.

Thus, each time a data representation change;,. every module. that imeracrs with that data

must be modified to incorpomte the change. G iven that data representations change

with relative frequency , corresponding procedure modifications would be needed often.

The greater the number of modules and processes that interact with the dma, the more

likely that an update will not be perfom1ed properly.

The use of ~bsmtcted data represemations results in a much different scenario.

When a data represenwtion changes. o nly the module (class) that implements that

repre;,cnt:uion needs to be modified. Mcx.lu!es only h<tve knowledge about the

i nterfaces of other 111odules. und such knowledge is much less likely to change. This

msulates orher processe~ and modules from requir ing modillcation whenever dnta

representation changes.

Parnas proposes that a reason<tble course of action is to begin by generating a

l isr of difticul t design decisions and design d.eci,.inn;; thar are l ikely to change. It is

further recommended that each module he tksigned tn hide decisions from the other

modules.

Time Frame for Learn ing. T he advanta g e~ of encapsulation have been

tmtltrs tooti by structured programmers r'or many y~<trs. :V1eyer argues that

mexperienced programmerx c:u1 underorand th.: ne.:d for e-ncapsulatton with in a few

rnrnutes I MeyerY31. :V!any sraw. bowever. that both srrucrured programmers and

nov tces will requ ire a number of weeks of cxpdience with a few small projects before

learning how to effectively cnlploy the .;ncap~u l<ttion mechan i~'lns rhat object-oriented

bnguages prov ide I Meyer9:'. Whiti ng9~1.

10

:0.11es~age P11ssing

Description. Objects are encapsulations of entity abstractions and respond to

requests made by other objects via message passing. When an object receives a message, it invokes the method associated with that message. These messages are formally speciried and compnse the intcrface to ;he objecL The in terface to an object i'

the only i n fom1ation that other objectS should have to know about As speci fied in the

section entitled Rel inquishing Pros:ess-01;e!Hed Th inking, this method of

communication is often <.lifticult for novices ro concepwalize.

A more technical problem that nov ice~ often have w ith message passing is a concern about performance penalties I Wilson!(8, Pamas72a]. Encapsulation inrroduces

a new kvd of i ndirectiqn. Proce.sses can no longer directly manipulate data. lnstead,

un object must be sent a message to perfo:nn the desired operation. U pon receiv ing

such a message, the object may invoke multip le methods upon itself in orde.r to perfom1

the desired action. Concern about perfotmance penaltie> can make the user grnnt other

objects direct access to instance variables and methods used for internal support. Such

acce>s is almost invariably a mistake bec;wse it v iolates encapsulation.

Potential Solutions. The literature provi(k; verv little infom1ation that

addresses the concepwal difficulties of message passing. A set of diagrams, developed

by Cunningham and Beck. have been use9 to teach over I()() students the concept of

message passing ICunninghamXol. Cunningham ;tnd Beck attribute their success tO the

omission of"object state" a11d "message sequence" from thei r technique. This

omission, they arg\te, facil itate' under,tanding (It the rel:uionships between ciasses a, indicated by the messages.

When performance is a primary conc~rn. more eflicient languages may be the

only solutio n. Thi$ ;;.hapter does not compan: I he ~tTiciency or speed of process and

object-oriented languages.

Time Frame for Le3mjng. Both :vleycr and Whiting bel ieve that the concept of

message passing can be learned wirhin a few minutes tO a few hours [rvfeyet'93.

Whtring931. Wlliting bel ieves that more experienced srrucwred programmers may

requ ire addi tional rime tor learning the concept of message passing than thoeir

Inexperienced counterp<tns. There i ~ no rormal <:\•itknce tO ~uppon this clain1.

Objeq Decomoosi lion

Desctiprion. When attempti ng object decomposition, novices frequemlv

~ncoumer a number of clifficu lt i~s. t.:sers whr> h:tw not relinquished process-oriented

II

thinking, often trnnsfonn prO<:cdut~tl abstrat:tions directly mto objects [Henderson9 I.

0Shea861. In other words. an attempt is made to wrn a process imo an objecr.

Consequemly, the processes I hat act on the clara. instead of the dam themselves,

become the objects. While this is possible. i ris almost always a bad idea. Pamas

argues that the data representati ons are mo~t likely to change and should be

encapsulaTed [P:tmas7~al . There are ~enain application areas. however. when~

processes chmtgc: atlea:,t u~ l>ften as the data repn!S<!ntmion:, on which rhey act. The~e

inc lude experimental. .:omputational. and utili ty pn:x.:esses. In these cases, it may bl!

more appropriate tO ab$traci the processes them,;elves [Coggins93!.

Novices may be tempted to usc this tdea as an excuse tO map all procedural

abstractions to objects. Given the fundamental imponance of overcoming process­

oriented thinking. i r may be prudem to avoid inu·oducing the concept of procedure

absrraction unti l after object-oriented rhinkmg ha~ bee.n n'ktstered.

When anempting to define a new cla~s. novices h~ve been observed groupmg

emi1ies by stme atTributes of !es:;er imponan~e while ignoring more. imponam attribute>

or behaviors. Gibson illustTiiles with the following .:xercise. On a sheet of paper, Ibr

the features of an apple. Upon completing rhi~ I isr. record a second list of features of

an imitation apple. Most individuals whn complete th is exercise. find the two lists are

vinually identi cal except that rhe second list might include " inedible" or " for display

only". Although the roles of two objects may be quite different. novices may group

them due to thei r sim1lar state [Gibson9 11. r\ ~i111 plcrcxample is that of a house and a

person. Both a house and a person have an address and. therefore. share some

common state. G iven the degree of disstmrl<trny be tween the tWo obj ecrs. i t is probably

not appropria te 10 try tt> repre~em tile:n m one cl as>. Experts recogn ize the necessity of

c.~amining those qualities thar distingui!>h an enti 1~ from others when creating a

potential class.

TI1e lack of toots to help programmer;; perform analysis and design hinder$

object decomposirion. Cw·renrly. implemc:mati<m re~ource~ i nclude editors, compiler:;.

i inkers, debuggers and <:1:1;,, browsers. Whik thc:'e tools are helpful during the

implementation phase of a '"ftw:tre >ystem. ace<.:'' to tools that help wi th anulyots and

ue>igu <ue uecueu. Such «Kllo could potcntiallv prevent the acceptance of cont1icring

requirements. en,ttre the <.:nrnplereness ot t:nc:tpsLJI;ruon. and verify that design

dectsions can be nnplememeJ with :1 'pcct licd rmgr~numng language. The availahllit~·

of .;uch tools IS lim tteu.

r-.;ovices are usually in troduced U> pro~:-'Tamming concepts through a popular

!anguage. In the case nf ohiect-nriemecl prottramming. rhe language is typ ically

I ~

Smalhalk. C++, or Eiffel, while in the case of proc~ss-orientcd programming it is

usual ly C. FORTRA.'i. or flASIC. Novices are rarely i ntroduced to programming

through training for process or obj ect-oriented analysis and design [Coggins90aJ.

Most universities and <;orporations trust that the user will learn these ski lls through

experience. Gibson argues that a pattern s.imilar to what occurred during the early years

of structured programming i;, rcem~rging. Th~ novice is lirst introduced to a language

and over time re~lize$ that his or her implementation str:uegy is flawed as a result of

poor design. The novice seeks out and adopts techniques to help with design and, after

time. realizes that a poor understanding of the original problem is responsible for

design t1aws. Gibson believes thm this pat tern of implement:nion. design. and analysis

is extTemely common and is not confined to novices 1Gibson9lj.

Potential Solmions. There are a number or techniques available for pcrfo1111ing

object-oriemed analysis ;1nd design. These are de$Cribed in the following chapter.

Only a few of them are idemitied as be in~ suited for use by novices. One such merhocl

has been proposed by Beck and Cunningham I Be•·k891, who repon successfully

teaching object-oriented thinking. analysi::;. and design to over I 00 studenrs using CRC

c:ards and an exercise .:onsisting of "what-i f ' scenarios. T hrough this exercise. novices

are allowed to graaually build on their knowledge of a given problem domain. During

this process. analysis and design q ueslions are raised. The i nstructor provides the

swdents wi th assistance in these decisions. CRC cards have also been used

successfully in industry 1Coplien9J 1- Th is ltdmique will be discussed more

thoroughly i n the nexr chapter.

Another apparemly useful rechnique is thm of play acting. In play acring.

students ''become" obje<:t:; :111d attempt to i meract ~~ ith one another until they are able t(l

identify theiT responsibil inc:s and relationship~. T his technique seems panicularly

usc:ful for demonstrating that i nstances of a dass have the same methods and attribute~

~ but possibly d i fferent v~lues for those :nuibute.s). Additionally, it appears to help

studems detl!rmine what diffc;:rent types of rela tit.mships among objects are possible

I Pugh88, Whiting90. RossonR<)I . This techn iq ue wi ll be discussed more thoroughl y in

the next chapter.

Wilson has successfully utilize<i :1 !lll r<i technique: [Wi l~onRR ] The insmu.:wr

f irst designs o smoll program using SlnH.::ured ~n:rl ysis and design methods. :-l~xt. the

srudems :t re guided in "ewnting the program usin~ object-oriented analysis and design

t)lethods.

I ]

Inheritance

Descriotion. Novices often attempt to u.se inheritance (is-a) relationships when

clienc-of. server-of, or pan-of relationships might be more appropriate [Pugh88]. For

example, a novice might mistakenly create a class TextEditor by inheriting from class

Memory Manager. An instance of class TextEdi tor might contact an instance of class

Memory Manager and request a needed amount of memory. In this example, a

TextEditor might require essential services from a Memory Manager, but that doesn't

mean that a TextEditor is a MemoryManager so inheri tance is not appropriate. Given

this context, a client-of relationship is more suitable.

Instances of two different classes may also have a pan-of re lationship. For

example, an instance of class Car might bave an atoibu te (state variable) that is an

instance of class Engine. Class Engine should not inherit from class Car because

engines do not behave like cars. An Engine is a pan of a car and inheritance is not

warranted in this case.

The literature appears to be at least partially responsible for the confusion

regarding the possible types of relationships among objects. This is particularly O'Ue in

many articles that auemptto justiiy the use of multiple inheritance [Meyer88,

Booch9l a]. One of the more well known examples of this is the food, fruit, sp ice,

apple, cinnamon, apple pie example (figure I . I ).

In this example, the use of multiple inheritance is promoted in an attempt to

demonstrate that an apple pie can inherit the qualities of both apple and cinnamon,

saving the

fruit

~ apple

food

Figwe l . I

Apple Pie

spice

~ cinnamon

I ~

user from creating duplicate code. The problem wirh this example and with most

~imi lar examples is that an apple pie is neither a fruit, an apple, a spice, or cinnamon.

An apple pic coma ins those items bu t that does not mean it should inherit from them.

Certainly, a pan-o f rel<uionship would be more appropriate.

Once novices become reasonablv ad~pt at conw t 1cting inheritance relanonsh1ps.

they begin tO construct larger. more complex inhemance hierarchies. Since analys;s

and design are usually iterati ve. the nov1ce hegms to inrroduce new attributes and

methods into the c lass hierarchy. Because. it is often di fficult to decide where to place

new attributes and methods. novices often place auributes and methods in an

inappropriate cbss withm the hierarchy, T his can resull in poor correspondence

between the abmaction ::tnd the differem levd~ of the hierarchy !0SheaS6] .

Eventually. an incomprehensible hierarchy is produced. Poor abstractions are often the

result of nor understanding how general or specific a given dass should be

I Sandberg86] .

i\ related problem invol ve$ the technic:1l difticulties that exist in large and

complex hierarch ies. Often. hierarchies are so immense thill it is difficult for the novice

to determine wh ich classes are the most appropriate to usc [0Shea86, Beck88,

Linron87 ]. Future tools for examining class l ibr;u·ies may help alleviate this problem

[Fontana91, deCh<~mpeaux9 1. 0Shea861. Although Meyer asserts that this complain t

is exaggerated [MeyeJ')O], most would agree that it is imponant tO understand rhe layers

o f :~bstracuon in a library before attempting ro liSe n. and that such tools are necessary

ro help understand the abwactions a library encapsulates I Bcck88] .

A n issue related more tO reuse than i nheritance is the re1uctance by both novice~

and experts to reuse cmle written by other individuals. Thi$ resist~ nee to "outside"

code is likely the resu lt of many programmer;' dc:-.1re to control tht: software product as

much as possible I McKennai\8. Fonr:lna'll . Griss\1 11. This problem is perpetua red by

many managers who wi ll not purchas<o: ,oftw"re irom outs1de sources because they

beiieve it is easier and/or cheaper 10 wme 1n·housc. :vtost do 1101 rea lize how difficult i t

IS 10 develop rrulv good software IGnss') I 1. Fear m:tv be the primary re:.~son thm reuse

is not done on a larger scale.

Pocenrial Solupons. Techniyues t'or le;lllung object-oriented progm mming are

remarKablv st!em nn ;he subjecr or i nheri t::tnce. $hater d aims that design for reuse IS

d ifficult. and cvc:n rn(.lrc difficu lt to teach I PughXi\ 1. Th is argument is generally

supported by the. li termure. It may be po:-.~i b h: to u,e Wilson's method o f teaching by

exam pit". to convt:y th~ me:1n in<! ,llld us<.: r>f i nheri1:1nce 10 novices. Thi~ technique.

lS

lwwever, requires the :tvai lability of a qual if ied teacher. Until more techniques are

available. novices w ithout teachers will likely resign themselves ro the study of exist ing

c lass hierarchies <l$ a means of leorning inheritance. A good set of class browsers or a

rich environment such a~ Sm~lha l k's would be helpful in this efforL

Time Frame for Learning. Many c la im thm the concept and purpose of

inheritance can be learned in a few hours'<' a few days f \cleyet9JI. Others claims lhat

the proper use of inheritance can take months or ~ears of experience. During this time.

he swtes. a user wil l develop a rersonal philosophy on how to employ inheritance

based on the advantages and di sadvamages o f the mechanism l Whiting93l.

Sun1marv

W hile there is a great deal of advice on the best ways for beginners to overcome

the di fficulties of object-oriented programming, [ here is little formal study. A

univer~olly occepted recommendation is that nov ices should detennine how expertS

learn these concepts and t~ to mimic them 1Gibson9J]. The difficully i n applying ihis

"technique" is thar experts cannot always explain how they learned the necessary

concepts. Often. experts can only describe the products of their learning but not the

underlying process of their learning.

Because languages are taught more frequently than programming concepts,

there is more data available for gauging the lengt h of time necessary to learn a particular

programming language. M any daim that Smalltalk can be teamed in a couple of davs.

Such claims do nmtake into account the more difficult aspects of how to use

c:nc~psu l ation and inh<::tiwncc etfe~:tively. St>me ~!aim thar the teaming curve for C"-+

is approximate lv 6months wh iie Jossman ;tat<.:s that it is or1e ye::tr I Jos5rnan90j. The~e

daims appear to conform with the litera ture.

Beck concludes that inenia. lack or experience and a luck of teach ing tools and

me thodologie$ are prevenung obj~ct-onellted progranumng from being effecrively

dis5eminatecl [Beck811[. While ume w1i lundoubredl y :;olve !he problems of inerna and

inexperience. 11 JS more dif ficult to predict how the la~k of tools :md methodol<!gtes wil l

he resolved . • tnd how thetr Hhsence wt tl affect I he :tl)tl tue~ ot mose usmg ObJeCt­

oriemed languages.

((>

Chapter Two:

OBJ EC!' DE COM POSITION

Frequently, an attempt IO map <t problem domain to a set of abstractions is made

under the false assumption that the problem domain is understood at a level nec.:ssary

for implememation. A> tht: implernem:uion progre~ses, unexpected dependencies in the

problem domain are discovered and the original ab>tractions are modified tO handle

these "except ions". Upon completion, the absrractions poorly represent the problem

domain. The class library is vinually incomprehensible. cannot be reused. and

ultimately is discarded.

Object decomposition is an iterative process. Since refinemen t of the model of

the problem domain is unavoidable, one must expect the obsrractions that represent it

and the implementation of rhe abstractions. to change. Relationships and interactions

evolve in this manner [Fonwna91]. I f a class library is to withstand the demands of

fu ture needs. abstraclions must be designed ~nd implemented with change in mind.

The problem of t:volving classes and th~ir re lationships is funher compounded

by the lack of easy to u,;c r'ormal ana lysis and design techniques. Many programmers

and managers view programming a$ an an. and -:onclude that it is unnecessary to teach

the fundamentals of analysis and design to students ~nd employees. Many individuals

aiso assume that other progn1mmers will understand a problem domain as they do and.

therefore, decompose a problem domain a~ th.:y would. Additionally, the same

problem domain is frequently broken down into different absn·actions by different

individuals. As a programmer gains experience with object-oriented programming, the

preferred style of tlect>mposition may change. The difference between a poor system

and an exceptionaJ one depends upon how the abstractions are dt:veloped and related.

The process Qt' deren11ining how a set of abstrolctinn~ rc1atc and interact l~ad:s to fun:hcr

rcr!nemt:nr of the o1igi nal s.:t of abstraction~.

This <.:haprer presems a ser of critt:ri:J for guiding both the process of object

decomposition and the .:valuatinn of .:ompleted decomposit ions. It rhen reviews and

compares a number of methods for the dec;omposition of problem domains. lt

concludes with a brief discussinn on the advamnt;!CS and disadvantages of using

techniques that transfom1 stntctured nnalysi' and <ksign resu ltS to object oriented

design specifications.

TI1ere are many arguments over the effectiveness of these methods due to their

informality and f;~i lure to address such basic issues as inher itance and maintenance.

Fom1ality ean be expressed on two levels. The formality of the heurisdc used to

decompose a problem dotnain is imponam because it can aid use rs in deriving a

superior set of classes with which to represent the problem domain. The formality of

the expression of the discovered classes is imponam in relaying infom1adon to clienrs

and in the implementation o r analysis and design results. This chapterShows that most

object-otiemed decomposition methods lack both qualities.

Definitions

Ohjecr Decomposit ion. O~ject decomposition refers tO a th ree part process .

First, the problem and i L'> doma in are examined. Next, a set of entities which

adequately represen t the problem domain are extracted. Finally, the set of extracted

ent ities are refined imo a new set of emities whil:h are supponed by a programming

language.

Object-Oriented Analvsis. Object onented an<tlysis refers to the fLrst two parts

of tile object decomposition process. No tht)ugh t i~ given to the implementation of the

abstractions. As stated by Coad and Yourdon, analysis is "the process of exrracring the

'needs' of a system- what the system must do to ~atisfy the clien t. not how the system

will be implemented" )Coad\l la) .

Objeq-Orienred Design Object oriemed d.,:sign refers to the third pan of tl1e

object decomposition process. Coad and Yourdo n write. "design is the practice of

caking a specification of extemally observable behavior and adding derails needed for

;lctual computer system implementation" I C<>ad9 I bl.

Guidel ines for the Evaluation and Development of Object Decomposition

Two top ics are discussed in this section. First, a number of criteria are

identified by which th.: yu"l ity of objec.r decomposi tion can be evalunt~.d. Next.

gu idelines for the developmen t o f good t)h,iet:r demmposirion are outlined.

Evaluation of Qhj~cL Ds;composirion

There are many <.:ha racteristics of a good softw;tre product. However , object·

oriented programming addresses only char<~ct~:ri"tics related to modularity. The

IX

modularity of a system can be evaluated using five cri teria which are as follows:

modular decomposabi li ty. modular composabil ity . modular understandability, modulnr

cominuity, and modular protection IMeyer&S].

Modular Decomnosahilirv. The decomposition of the problem domain

decomposes the problem into several subproblems whose solu tions may then be

pursued sep:u·atei y !divide :Uld l:Onquer).

Modular Comoosahdirv . T he decomposition ot' the problem domain p roduces

software elements which may be freely combined t<> produce new systems, possibly in

an environment quite different from the one i n which they were initially developed.

Modular Understandahilirv. The decomposition of the problem domain

produces software elements wh ich can be under$tood individually by the user.

:V!qdular Conrinuitv. A ~mall change in a prohlem iipec ific:uion res.ults i n a

change of on ly a few modui.::s.

Modular Protec<ion. The effect of an ~bnorm~ l condition occurring m run-time

in a module will rema1n contined to thai moduk. or Jt lenst will propagate to onlv a few

ne1ghboring modules.

Development of Gooc! Qbjeq Decomposition

There are a number of guide! i nes for rhe de ve!opmem of good object

decomposi tion. Some characteristics can be checked during the development phase.

These characteristics include the following: in fonnarion hiding, understandability,

completeness. t'ew couplings. wea" coupling~. <:XI)Iici t couplings. ~ufficiency. and

primitiveness.

Information Hidina .. '\l l i nt'onnauon abt>tll a module should be private to the

module unless It is spedficallv needed and declared public I Meyer88. Pamas72a.

Strousrmp88j.

Undersrandabiiitv. '-'l<XIules must ...:orre~pond Io ,ynu1cric unns in the language

use.d [Yieyer88].

Complerenes~. Tile ime:1nt:c nr the 111odule is general enough tO be used by anv

.;l iem I Booch91 a. Stro11s1rup~l'l l .

Fe'"" Cnuniing;{. Ev...:ry rnoduk "houfd \..':Onmlunic:-t rc wilh as few others ;.s:')

nossi ble 1 MeyerclS (.

Weak Coup lin ~s. ff ,Jny <wo mnduic::; ~ommunic:ue :n all. they should

~xchnng<: as !inle informauon a; possible I i'vleyerxX. Booch9 ! u. Parnasna 1. Expl ici< Coupli ng;;, Whenever <wo moduks A and B communicate, it must be

obvious f rom che text or t\ and B I MeverX.Ii 1.

19

Suflkiencv. The module caplllres enough char.Jcterisrics of the abslr.lction to

p.:rmir meaningful and efficient interaction 113ooch\lla].

Primitiveness. ll igh lcvd opera tion> may be better accomplished through u set

o f lower level openllit111' ttlm, must be balanced '-~ uh efficiency) !Booch9 1al.

\ ls:Th<Xls ,-\ vailahle r~>r Otwt:J Des:ompositwn

There .tre .1 vanety oi ln<!thods avml;~t>le to atd the user in object decomposioon.

Four groups of method~ are d iscussed: guideline: meThods, text analysis methods,

re'ponsibiliry driven meThods. and structured analy~is/exrraction methods. The fiN

three groups are primarily b<t,ed on object-ori~ntcd l<:chniques, while the lasr group is

composed of modifit!cl procc,s-oriented techmqt lc'·

Gtndeli ne Ylerhod~

Guideline method> typically provide a li,t of the kind of objectS the user should

look for within the problem domain. In addiuon. they often provide guidance for

te>ting the validity of the candidate objects. Two c.x:Hllplcs of guiddine methods are

object-oriented analysb nnd information mode ling.

Object Oliemed AoalvSJS. This method was developed by Coad and Yourdon.

h is presented as a techn ique which builds upon 1nt'orrnation modeling [Fichm:tn92].

"ith the addition of the concepts of inheritance. fllCthods. and messages

tlt:Cham!JC:lux92). Object decomposiunn "de~nbed in terms of five phase~: clas~ &.

ObJCCt discovery. srrul-ture tomlation. subjet't de,mpuon. amibure formauon. :lnd

m~thod fom1alion. For cl~~' .tnd l)bJeCt Ji~.;nvcry. me u":r i~ given a set of concepts

for which the problem domain must be ~x~umned. The types of relationships among

.:ia~s.:~ are derenmned dunng th<! StrJcture tonnauon pha,c:. During the wbject

Jescription phase. the discoven:d classes are 'egregated toto groups of related classe>.

Tne purpose of ;his ph:t~ I\ not to detemnne rd;.~uon~llips Jmong da~es. but to help

:he user group p01enually large :1umber:. ollta."c' uno J "nailer set of \Ubjec1s. This

helps to prov1dc an uv.:rvtew or the .1b>tra<.:Hnlh •II the problem domain. The rinaltwo

pn:.u;es 1nvolve the 1dCnt1i1cauon or' arn·•Ot.ne:-. ant.f na:lluxls. respecnvety. i\ dHfcrcm

d1agram 1s used to c:xpr~'' resultS ,ll ~:td1 nt th~ r 1"<: pha'c' of object decomp<>>Hion

tigu re ~. !).

[n the tir't pha,.:. u":rs uiswvcr d<t"~' w1thtn the problem doma in by looking

for >tructure~. other >y,telll\. device:._ thing~ or event~ rc:membered. roles played.

<)oerauonal procedure,. ,ito;:,. 1nd orgamz:mnnal unit~. Structur<!s 3re detined as <!it her

generalization-specialization (is-a) or whole-pan (pan-of) relationships. Since Coad

and Yourdon believe this to be the best area in which to search for potential classes, it is

discussed in greater detail in the second of the five phases. Other systems are those

entities outside the problem domain that interact with entities within the problem

domain. This ambiguous definition of other systems suggesL~ that the technique dO~$

not provide much guidance in determining the boundaries of a problem domain.

1 1 C/ass-&-Obiect Class

Class-&-Object Name (top section) Class

Attribute1 A ttribute1 Attribute2 Attributes (mirJdfe section) Attribute2

Service1 Services (bottom section)

Service1 Service2 Service2

Generaliza1ion a Gen-Spec S tJuCl!Jte rl ~1 ':t I I

Whole-Pan Strucrute

Speeialization1 Specialization2 f3 E3 Class-&-Object1

' Instance Connection Class-&-Object2

•.m

B Receiver Message Connection

1 1

Subjecr (may be expancJecJ or collapsed) NG!~: In cl!dltiOrt, GOA L'Ses Obf~l Stitt OiaQtams and Str~tct Charts for s\)ecdyinQ SeMen.

Figure :!.1

Object Oriented Analysis Di:tgrams iCoad9 lal

ll

Devices are defined a' any ~ystem "l!han the problem domain and are.

consequently. poorly deli ned. TI1ings or events remembered are records of

transactions within the o;y, tem or reco<ds of hi>loncJ I evcnl!> "Within the ,ystem. Roles

played are 1he responsibil ities that differem wmpC~nems wi1hin the domain have.

Operational procedure' are responsibilities lhatthc ..:xamined sys1em mus1 provide over

time. Siles <u-e the phy,ical locations of the enuue, or 1he problem domain. Finally.

organiz;uional uni1s ane 1he 'lructural componenl" 1ha1 people impose upon thcmselve,

and other entiues.

TI1e amhors provide a list of hints on how tO find classes within 1he problem

domain. These include observing 1he problem donwin lir.;1 hand and actively li s1ening

to people who work within it. lmerviews c;~n hel11 to cletennine exactly how th<.:

domain functions. Reading aboutlhe problt:m dnm;tin i' necessary. Checking results

obtained by others modeling the same or 'inular dl'main• is also invaluable; this ts also

an almost completely ignored fom1 of reuse. Fun her candidate classes may rewa!

thc:m~elves when the u~er begins to protOIYJlt!.

Once a St:t of candidate classes is obtained. i1 must be rested for validity. The

au thors provide the following questions for tc~tin g pot~ntia! cla>st:s:

• Do instan<:es of thts c lass need to be referred to over time?

• Does the clas' prov1de a behavior n<X·e"ar: to the problem domain and the

solution'

• Does the candidate da,s have multiple .u tnhtnes·•

• Is there more than one ins1ance of the c l ~hs?

• Are the attrihult.:S and me1hods applkabk for all in>lances of the c lass?

• Does the candid at~ da>> fu ltlll <HI atwal r~quiro::menr of the system?

According 10 thb me1hod. a candida1e ..:Ia" 1h:u passes these lests is probably

\:!lid.

In 1he structure fom1:mon phase. th~: tN:r <"\amines the set of c lasses for is-a

and pan·of relationship,. The technique doe' •H>t (>iTer much guidance as to how thi ,;

task might be accompl i ~hcd. The user exam111.:s ..:ach dass in tum to determine if one:

.;l:ls' is a specialization of another. For detenn111ing pnn-of relationship~. the authOr>

recommend looking for a:-:;embly-p3n. conratner·l"Ont~m,, and collection·mernbcr

nelation~hips be;ween d;t"t:' . \Vi1h thi' infnronauon. a 'ct of class hierarchic~

ctncrge~.

During the sub~ct description pha~c. tho: root class of each structure is

identified, and each cla~s not in a sllllcture is ide nulled. The tdemified clnsses are

designated as subjects. Coad and Yourdo n describe a subject as "a mechanism for

guiding a re:tder (analyst, problem domain cxp.:n. manager. c lient) through a large,

complex model. Subjects an: also helpful for organizing work packages on larger

projects bns.::d upon Jntual object-oriented analy~h investigations" I Coad~ Ia).

During the iounh and filth pha~~. ;~llnbut<:'> and methods are identified. The

aurhors sugge)t the cxamin:uion or' prev1ou' ob;cct-oriemed analy~ts results but provtdo:

li mited guid:1n<.:c in how the vaJidity oi an Jttnbtue or mer hod may be tested. It is then

de1em1in.:d whether in,lt1nces of a ci:l;~ bdt<W.: di1Terently according tO the value of

their attributes. If so, additional me1hotls may be required. Method discovery is

accomplished primarily through the detcrnu nnt ion o f 1he necessary services that a cl:llis

must prOvtdt: for both H~cl f and other cJ;t,,e,, and the: ncco:ssary servtces that the class

receives from other cla~ses.

This technique has both strength~ and weaknesses. Although the five phases

are accomplished primarily through a set of infom1al hints and tests. it is a well

thought-out and relatively coherenttechnk111e. Additionally. the object diagr.u11S

provided in each of the five phases do lend themselves towards greater formality than

most methods. For further infonnation about this technique. the reader is referred to

the work of Coad and Yourdon [Coad91a. Coad91bl.

lnfomla!jon \-lodeling. Similar to ohjcct-oriemed analysis. infomtation

modeling as develotlea hy Shlaer ;tnd \ic:ilor JShlacnlXI provtdes a set or conceptS

which can be u~cd ,n the ~xamin ation ot a prnhkm aomain. It also provides a set of

que~nons for tesung the validity or' a candidate da;,s and a set of diagrams to aid in the

formai izaLion of nnaly~ts results. it also atiC111p1S 10 add ress the issut: of inheritance

with a set ot entity·relat tonshtp diagranl\. f'l nallv. 11 pnwides gre;tter support in

attribute discovery .

lnformauon modeling prov:des '.:veml concepts to aid with object !ormation:

mese include tangthle thtng~. role!>. incnJcnt,. tnter.twon~. and ''Pectfication objeCL\.

Tangible thing> an: <.::tpaole uf bemg touched. Role> are function~ that deii ne a

partic.ui:.l r objt:ct. lnctde-nt~ ..u-c u.-scd to r..:.pn::l...:nt .m OCCUITCncc or .1 ~~e~ili(.; ~vent.

ln tcraction~.nr lntCJ'tKIIOII object, . geJh;rull)' have :t "trnnsacnon" or "con tract" 4uali ry .

• llld relate •Jbjccts 111 rhe model. Spel:uicaunn nbjcct:-. hav.: the 4uahty oi a srandard or a

Jefimuon oi other OOJtCIS.

lJ pon obtammi= ,1 >ct of candidate ~.·la,..es. :1 wntten ~rip non of each class is

m~de. The de-.cripuon con<hlS l>i :1 name .md a ,i,on. inionn:mve Statcmcm. Thh

statement allow$ one ro detem1ine whetll.:r a [Xtni<:ular re;d world entiry is an instance of

the clnss as conceptual ized. Once descripuons have been written for each class. !hey

are tested tor validity using a series of rem. The unifomlity test requires each instance

of a class to have the same char~cterisrics and to be subject to the same rules. Tite

more-than-a-name test s<mes rhar if a candidate da:;s has no attributes and no

characteristics orher than i ts name. it is probably not a class but <Ul attribute. The OR

rest srares rhar if the clas~ description uses the:: word "or" in a significant way, then ir i<

probably not a class but a group ol' classes. Finally. the more- th<Ul-a- lisr tesr stares that

if the class description i~ merely a list of ;til rhe specific i nstance.~, ir is probably nor a

class.

Once the user has written descriptions of each cand idate c lass, !he process of

artribme definition is mitiated. The Shlaer <lnd Mellor mer hod of object decompositi on

is more helpful than the. Coad and Yourdon method in the creation of attributes. Unlike

many of the methods p resenr~d m this ehaprer. th1s technique places great emphasis on

what should be and should not be an amibute. For example. the authors state that

artribures should be mumallv i ndependent in order to prevent conflicting internal state

values. They should be complete enough to express all possible imernal states of the

class. They should abo caprure separate aspects of the object abstraction. Each

attribu te, like each clas~. is given a description. This description consists of a shon

statement of purpose for the al!libure and a specification of the domain or range of

values thar a given attribu te might have. T he dom;lin of an anribute can be specified by

enumeration. citation . . 1cceprance rules. r:tn!'c . ",arne a~" . or using :1 spc::cial "see

above" explanation.

Once aU attribute descripnons have been written. the user begins describing rhe

relationships of the cl:t;;ses 10 one another through the use of graphic and text diagmms.

These diagrams. in order or use. are: lnt'onn:HJO!l Srrucwrc Design (an entity ­

relationslllp di agram with :mnbures mduded - tl gure 2.2). Overview Information

Structure Design (anorher entity-relationship diagram without artribures- figure 2.3),

Object Specifica1ion Document (all dass ,IJ1CI ;un;bute de~criptions). Relationship

Spec ification Document (indicure$ ut i relariDnship,;l. and Summary Specitication~

~ i ndicate$ ..111 aunburc:; . methods. and relmionsh1 p::d.

Like Cnad and Yourdon. Shlaer and Mel l or providt: a set of diagrams m :tn

~nernpr to tom1al ize a descrirt ion of the re~ultint:~ ..:las" Mructurc. bm nffer li ttle

gllrdance for the actual de:cnninarion nf cJas, stn.tcture. Fun her. there is little guidance

for method d iscovery .

COMMlnH Ia made CLUB MEMBER

• commmeo c . up of • rn~mber Offl'\t name • addreu

• 101"-81 servas • d\1-U pa1CI tft annbu-te'Sl on <!ate

COMMITTEE M EM8ERSk1P

•mo~rNm•

• ~0mm1ttoo ntft\41

F. ., ., tgure -·-

lnfomlation Structure Design [Shlaer88]

OOG OWNER OWM UCENSEJ) OOG

iaown.ct by

Figure 2.3

Overview Information Structure Design [Shlaer88)

Text Analvsis Methods

Unlike the guidance methods presented above, text analysis methods require the

user to examine text descriptions of both the problem domain and a solution Strategy.

Nouns and verbs within the text descriptions are identified and mapped to objects and

methods. A number of similar techniques are avo ilable. Rather than present each one

individually. they are presented as a composite with attributes unique tO a particular

technique noted.

This method. first proposed by Abbott (Abbon83], requires the user to State the

problem in clear, transcribed English. The user then reads the textual description of the

problem and extracts candidate objects and methods from rhe nouns and verb~ userl in

the problem description. This technique was minimally expanded by Booch for Ada

users [Booch91aj whi le Sincovec and Wiener added the use of modular design chans

( S i ncovec84].

This kind of technique typically consists of three iterative phases. In the first

ph:~se. an informal textual description of the problem domain and the solution strategy

is deveioped. The description of the solu tion strategy used to solve the problem must

use the same tem1inology as that found in 1he description of the problem domain.

Upon completing the two infonnal desctiptk>ns. rhe texmal description of the solution

strategy is fonn alized. During this second phase, the user identifies data types. object~.

operatCJrs, and conrrol consrr\lcts within the: text cle~cription. Common nouns become

candidate classes. Proper nmms and diro::ct references become candidates for instance>

o f a class. Verbs, predicates, or descriptive t!xpres:dons b<!come candidates for

methods. Adjectives become candidates for anrihutes. Control structures are often

implied by the structure of the Engl ish description. During the ideruification of these

elements. the original text description> may bt: refined. The final phase consists of the

segregatjon of the discove red classes. attribu tes. and methods into two groups : those

that formalize the problem domai n and those that fonnaliz<: the solution strategy. The

elements plnced imo the latter group con:;timte the dasses to be implemented.

As Abbott and Booch poim out, th is is really an iterat ive process [Booch83].

Neither believes that the process o f fonwliization in the second phase is so mechan ical

;1s to make the transformations automatic. As the user fom1aJizes the classes, methods.

and attributeS discovered through this process. add itional items emerge. Often, these

newly discovered items have no corresponding noun. verb, or adjective in either the

problem description or the solution strategy. Funhem1ore . it is often difficult tO

fonnalize some language beyond a cenain pnint. ;\bbon concedes that some

tr3nsformarions can be difficult.

An advantage of this technique is that users can detem11ne how formal to make

the problem ~nd strategy descriptions. For example. Abbott asks the user to

distinguish bem-een common nouns. proper noun>. direct references, mass nouns. and

noun phr:;ses. The user is given formal guidance on handling verbs. amibutes,

predicates, and deseriptiv.: expressions. Although this tech nique is initially

intimidating. most users are adequately ad~pt at the identification of nouns, verbs, and

adjectives. rouse it effectively . . 'vloreover. users can decide the level of t'omialiry they

wish w use. One potential disadvantage of this tlexi bil itv occurs when group members

:md clienrs disagree as to how fo1malto make de~criptions and transformations.

Anorher potemi;ll problem with this techn !que involves the relmionship between

language and thought. Since language and thought are intenwined. the words chosen

10 describe a problem domain are often a good way 10 communicate a problem to

others. The words. therefore. can be extremely v;1luable as class, method. and artribme

names. Frequemly, howl'vcr. <:nnc<:ptu;!l prohkm~ expre~~ed in words do not close ly

par:~lld the ongmal prohlem and dependence on a ~p.:cific d.:~Tiption may preclude a

superior solution based on a different imuuive foundalion.

An additional d iffku lry with this techn i4ue involves the imprec ision of human

language [LaddenS91. Mnny of th~ deti ni tiom, of common nouns and verbs are

difficult to aliicu lnre. Additionally. nouns are often applied tO concepts that are no t

fully tonned. :--:ouns .trc.: used to expre'\~ ~uch uu:1ngible entities as mass. unus of

measure. and other elu,tve concepts. Hendcr,on·Sellers and Con~t:mrine

I Henderson91) offer the example ofT .:xtEduor. a noun "hose semantics encompas«

both an abstract noun :1nd an op~ration . Whrk rcehniques are provided for

d istingu ishmg between these di fferent types of nouns. confusion about how to handle

even the mo~t common cases occurs readil y. L tdden argues that thi~ technique

"inherently lacb rigor uu~ to !11e impre<.:iSCIIt:" ()! the Englbh )(Uiguagc."

t:nlike the guideline methods prt:,ent<!d 111 the previa~ section. this technique

provides a mon: tom1al method of object diwovery. Rather than suggesting a set oi

concepts by which :1 problem domain may lx ex<~mined. a set of formal transformations

in iinding cla~-.e~. attributes. and methods through the process of idenlifying the

componen ts of sentences. are provided. Thi, ability makes it noteworthy and it is

unfo11unate that the cmities 10 which this forma l >et of transformation arc applied are so

unavoidably ambiguous. Although Sincovec and W iener have added rhe use of

diagran1s in an effo11 t<' further fom1alizc th~ techniQue. they do not appear to address

the tssue of inhcruanc.:. This ma~ be du.: rn the ;uuhors' empha~i> on the Ada

;>rogrnnuning languag.:

Responsjhili!Y·Pnvcn 'vlerhods

This group of rm:rhods is the rno>t poorly defined. t\11 of them decompose a

problem domain according ro the respon,ibilitics <'f emiues within u. Three response­

driven methods are di,ru»d below: r.:-.p<'n"bdity-dnven design. CRC cards. and

play ac~mg.

Re,nonSihJ!it,·-Dnven Destg't. Ot me method, ue,c:ihed mthis ,ection. Wirt\­

Brock ·' ResoorNbility-Dnven Destgn " tile 111l1'1 tormall WirtWOa ]. In this

tcchmyue. th<: prohtcm liOmarn ts ¢xamincd t'or drentl~erver relati{>rtsh ips. and the client

:utd server ennti..:s arc 1ran~fom1ed inro nltjc(;t\, It rs arg\led that this apprt1ach

maximizes mtormanon hitling and .:ncapMdauon hy deferring implcmemauon issues

unrii :u'!e~ :1 model m· .:la:"es anti th<!tr imeractron, i' in pi ace. It i~ also asserted dlat bv

t'Ocusing on obJeCt behaviOr. rather than OhJCl't >truc:ure. re"'ork is mmmnzed. The

'" _,

process i.s divided imo rwo phases: tile cxpk>ration phase and the hierarchy construction

phase.

The exp loration phase involves three steps. F irst, the user detem1ines an initial

set of candidate classes and atrributes, by cxrra~ing the nouns and adjectives within a

text description. Although these elements are fo~md through text analysis, it is not the

most noteworthy characteristic of this tech nique for object d iscovery. In step two,

responsibilitieS wnhw the sy;,tem :u-e assign~d w cl;rsses that comain related

infom1ation. Discoverc.J responsibi lities are evenly d ismbuted across all classe~ within

1he system. Tn step three .. the responsibi li ties for each class are examined. and tbe

classes which are needed for collaboration in order 10 fulfill each responsibility are

determined. A card is used to describe the responsibi lities and collaborators for each

class. These c<Uds were original ly proposed hy Cunningham and Beck I Beck89 1 and

are d iscussed below.

The hierarchy consmrction phase also involves thre.e steps. F irst, the methods

are placed as high as possible within the hierarchy. "Contracts'' are then developed

between classes. A contract is an agr~cment between two c lasses and specifies what

types of requests a client may make and how the server should respond to each reques1.

The concept of a comract has its roots in the clien!/server model and is helpful in

specifying the actions for which an entity is n:spon~ible. It is also helpful in

detennining what information (l &<iven emity shares. s~condly, a collabora tion graph

for the system of classes is created. The collaboration graph is used to identify those

groups of cl:tsses thar interact in a freq uent and complex manner. These groups of

c!:tsse~ arc designme(l a> subsystems. Cla;,ses within a ~ubsysrem should be strongly

imerdependent and support a small and s1rongly coho::sive.set of responsibilities. The

concept of ~t subsysiem ls sum far to Coad and Yourdon's Subjects concept, and can bt:

helpfu l in making o system with a large nurn~r o i' dasses more comprehensible The collaboration graph is also used 10 identify are:.s where encapsulation is violated and in

detemtining relationships thm are unnecessarily complex. Finall y, design specitications

for c lasses. subsystems and comracts are written Jnci the 'ignmures for all methods are

'pecified.

A weakness of th i:, ill<:thud i:. !hut rhe uso;:r •s provtded very little gu idance for its

us12;. One potential .JJvumclgc iO this technique i:\ thut it t llllY provide fur n1ore

..:omprehen;ible ab:;rrawon~. Svecificafly. n ~:mpha:;izes the dynamic relationships oi

.:lasses rather !han the , t:urc rdation;,hips rhat rnany ObJect decompos1don techniques

~mphas1ze fJ~chmanS>::] and th1s <:mphasis may resu lt in more comprehensible

abstracTions. Ho"ever. thJs conclusion is hrghly 'peculative.

28

CRC Cards. Class, Responsibili ty . and Collaboration (CRC) Cards were

developed by Cunningham and Beck 1Beck89. Cunningham86] in an attempt to teach

the basic concepts of object-oriemed analysis and design to novices. This method

consists of three steps. First, the user detennines a couple of the "obvious" entities of

the problem domain using any available method. fn the second step, a CRC card is

created for each enrity by dividing a 4 by 6 inch card into three regions (figure 2.4).

Account Transaction

Keeps balance and tralflc.

Remote DB

Transaction CardReader Validalf1 & perform Dispenser

money lraiiSfer. RemoteDB

L-Keep audit info. Actjon

Account

Figure 2.4

CRC Cards I Beck89]

The first region is designated for a. class name. The user must detennine an

appropriate name for the class although the method provides no assistance in this task.

The responsibilities of a c lass, stated in shon verb phrases, are listed in the second

region. Collaborators are listed in the th ir.d region. Collaborators are other classes of

objects with which the given class of objects must interact in order to accomplish their

responsibilities.

Upon completing the-cards, the user presents a number of "what-if' scenarios

related to the problem domain. These scenarios involve the classes already created, as

represented by thelr corresponding CRC cards. When a scenario calls for a

responsibihty that ts not covered by one of the classes already created, that

responsibility must either be added to one of rhe existing classes. or a new class. and

new CRC card, must be created that can address the new responsibility. In this

manner, the decompo~i tion of a problem domain progresses from the knowns to the

unknowns.

One of the benefits of this method is th:tt a u$er can quickly detennine whether a

L'lass is becoming too ''cluttered" with responsibilities and collaborators by examining

the lists on a given card. lf an obj~ct in t~racts " too much" with other objects, it is

probably due to poor design I Beck89[. Excessivt! numbers of responsibil ities may be

suggestive of a poorly detined class. tn which ca:-:e ir must be broken into components

with the responsioil ities distnbured ~unong then1 .

.Another advantage is that the canis can be held by the user as physical entities.

The authors of this method argue rhat this makes objects more " real" tO a novice and

facilitateS thought about responsibil ity and collaboration. The authors demonstrate this

ability in the rollowing:

We had videotaped experienced designers working out a problem[ .. [. Our cameras· placement made cards and the designers' hands visible but not tht! wrinng 011 the cards. Viewers or the tape h:ul no trouble following the dcvclopmem and often asked that the tape be stopped so that they could express their opinions. The most telling momems came when a viewer's explanation required thitt he poinr to a blurry card in the frozen image of the screen [Beck89 !.

Another advantage of this m<!lhod is that 1he cards can be placed 011 a table or

wall within spaual relation to each onother to indicate is-a. pan-of, client -of, an(! server­

of relationships. As refinement progresse;. card~ can easily be added, updated. or

discarded. The authors have stated that the ability to see cards spatially has revealed

holes within the decomposi tion. They report designers repeated ly referring to cards

they inrend to write by pointing to where they will pu1 them when completed .

. A. !though this method does not claim to be a <.:Omplete methodology, it has been

used ~uccessfully by a number of individual;; and ha; been incorporated inw other.

more complete techniques. such as Wirfs-Brock's re.;;ponsibil ity-driven approach.

L' nlike the di3grams us~d by orher methods. CRC card$ are not Stntic and more

brainstonning may result. Gec.aus~ the method pwvides little support for-inheri tHnce or

for rhe generation or the scr;:narios used in the th ird step. its use as a tool1o be

mcorporated into other. more comprehem;i ve methods may prove the most beneticial.

Plav Acting Piny acting involves member~ 0f an object decomposition team

pretending to be InStances or' dass~s which they are attempting to reline. A pt!rson

attempting to undersmnd the purpose or responsibil ity of .t class acts om a scenario

highlighting the rcspo1bibility in question with another member. For example. a group

mt!rnber attempting to detem1ine a responsibi lity of a TextEditor m:ty turn to a member

and S<ty. "OK. I'm a text editor and you ;~re the d i,k man3gement module. [f I give you

3()

(! tag identifier, ~m I responsible for the fom1at of that tag, or are you? Or maybe the

tag should be responsible for itself ." The person nddressed might then respond. "I

think rhat should be 1he rag's responsibi lity. f shouldn't know anything abou1 1ag

fom1:us.''

In !his exchange of words, people freque111lv ges!Ure wi1h hands to porrr3y 1he

pa~oing of informariorl l'rorn on.: objcct l person) to another object (another person).

Frequently. the people involved will address 1he other people as the c lass with which

!hey wam !he 01her person to be idemitled. In 1his manner, the person becomes an

instance of a class.

The me1hod of pl<lY acting is !he most informal of :til the responsibili !y-driven

me1hods. It provides no mechanism for object discovery. no notation for expressing a

system of classes .. and no faci li1ies for inhentance. With " few modifica!ions. if could

probably be used !'or process-onerHed decomposiuon. However, play acting h~s

demon:mmed its usefulness. I! tan b~ very hdpful in 1he refinement of classes already

discovered. Additionally, the behavior of play auing has been observed f requently in

group members of object decomposition teams. Like CRC cards, !his technique is

probably most helpful when incorporated i mo other me!l10ds.

Smtc!ured Analvsis Exrpcrion Me!hods

Smtcturcd analysis .:xrrac1ion me!h.ods all involve two distinct phases. In !he

first phase, structured analysis and design techmques are applied !O a problem domain.

In !he second pha;;e, the resuhs of !he fir$! phase are rransformed m order 10 extract!he

information necessary 10 create an objeC!-onemed design speciticanon.

There are :l grea! number or Eechniqucs ot. !his s1yle available. Thi s section

examines a few of •hem. The technique~ reviewed ;rre Objec! Oriemed RequirementS

Speciric3tion Method ! Baii inl\9!, Oiljen Orit:nted Design ! Seidewirz86] , and Object

Oriented Strucrured Design :vlerhod [W~s~.:nnanx9}. Th.:se me!hods provide u good

(;ross-section for this 'ry le of methodology. F~)r an insightful discussion on the

•megration of StntC!ur.:d and objecr·oriem.:d :lna!v,i:- and design techniques. see

I He nder~on9 I 1. Object (ki~nted Rt:ouirs;r"c"'~ Spc<:ilk:ui<Hl. Th is method. t'irst proposed by

Bai l in IB<ti ii nl$9. WardR9!. Jcpentis on \ tn.tcwred nnaly"s and design rechniques ro

c~ea1e a set of data-tlow diagrams descnbing the problem domain. Classes are

.:x1racted from !he da1a-l1ow d iagr<ml$ and u~ed ro construe! 3n en my-relationship

diagram. This emi ly -re lat i on~hip diagram i s u~ed to i ndicme classes and !heir

rda£ionshios and is helpfu l tn finding "Jlrnmrn it i~' fnr inherimnce al1hough it does not

31

provide any formal a~'"tancc: in this task. Although the methodology offers liule

..:oncerning the discov~ry of das,es, it doos provide 3 m.;chanism for refining classes.

This method con~bts of seven iterouve steps. 'llle seven steps are divided imo

two phases; the fi rst phnsc (steps I - 3) determin~s ;m initial set of candidate c lasses; the

second phase (steps 4 - 7) refine:; 1hose candid:uc: c lasses and adds additional classes

when appropnate.

In the iirst >tep ... e~ probicm domain ..:la;..x;.. are idennfied by creating datarlO\\

oi~gr.uns and c:xtracung the nouns from the proce's names. These names are u,ed a.~

.:andid:l re clas;e~. In "tep t\\·O. active clas>~:s an: diMingtnshed from passive classes.

Active classes posses, opemtons that de,cribe , ystcm requirements. Passive classes

possess operations which can be deferred umil the d.:sign phase. This is an imponant

bm somewhat ambiguou:. d i:.tinction. During ~tcp three. dataflow, are e:.tabli>hed

between active cla,~e' hy constntcting an objc<:H.latatlow diagram (called Emity

Datat1ow Diagrams) where acci' e cla:.se~ lxc•'me' procc's nodes and passive classes

lx-come either d:uaflo"' or data ,tores.

ln the second pha,e. classes and thetr mcthcxh arc decomposed into sub-classes

und sub-methods. A cl:h> is composed of wb·cl;ts~es tf the methods of a giVen class

define a set of clusses. New ObJCCt dnta-tlow diagntms are t•ecursivcly created for each

sub-class identified. In ~tep live, the object c.lata-1·1nw diagrams are exan1ined to verify

that all methods arc addr~;,sed by existing cla>'c". If not. new classes may be required.

In step six. all method' thm :tre periom1ed by or orl new da~es are identified. Classes

may be redesignated a' acuvc or pa:-,,ive at tht' pmnt. In 'tep seven. all da.sses are relegated to a ,pecific applicauon domam. Domain;.. are collections of collaboratmg

~bs,es. The>e individual domain> Jre :hen repre~en ted by an entity-relationsh ip

ubgram that can be u'l!d to help specify <:Ia,<~, :u1d their tmeraction ~ and for givtng an

overview of the system.

Tnis methoo oifc:rs little gurdance for 1he dt~.:overy of an initial set of clusses.

It doos. however. provrde two tes1s which the u,er ..:an e:nploy to help reline cla~sc:s.

l'lle :irst aetemune~ whether .:very known fuocuonat rcqurremenr ts met by one oi the:

cnnn~s- The ,econd dctcnntne;, whether 1hc llttcrnal 'tate of the sysrem i~ adequmeiy

rcprc~enct::o by the ~l~\tt!S or' the ..;nritje~. The: n1Hilf"-.: r by which th i~ mforn1arion is

,lc:!cnnined i~ not cxpl;nned.

One c.l ioadvanr:tge tn tfl i> sy,tem '' thut 11 I arh to effectively mcorporate rh.:

..:oncept of inhcnmncc:. The enwy-reiation,hrp dittgram; proouced in 'tcp ~even con be

hdpful even though the m.:thod dcxs not pn" ide :tn~· gutdance ior this process.

Ab<tractjon Analv«is. This technique. propos..'<! by Seidcwitz and Stark

1Seidewiu.86]. u:..:s atNraction analysb to tr;msiorrn structured analysis results imo a

diagram from which dasS<!S, obje<.:ts, und their rclauonships can be extracted. Like

Bailin's Object Otientcd Re4u irement~ Specifi<.:<Uion method, th is tcchnktue begin; with

the desctiption of a problem domain a, a ~<:t of d;ua-f!ow diagrams. Entities within the

diagram are idenufied and transfonned into ohject> through the process of abstraction

analysis.

Absrracrion analysb con,ists of three phases. During the ftrSt phase. the data­

flow diagram is examined for a "central emny". A central entity is defined as the

abstraction thut best represents the system being decomposed. To locate the central

entity. the user e.xnmincs the dam-tlow diagr:ull ror a set of processes and dnra stores

that are "the lllO>t :tbstract··.

In the second phase. enmies th<at 'uppon the cemrnl entity are identified by

following the data t1ow~ away from the c~:ntrJI cmity. The processes and data flows

that emanate from the l'CntrJI entity are then groupt.'d together in supponing entities.

The dara-flows emanating from the supporting ent111es are then examined in a ;imilar

manner. This proce~s is repeated until all procc~'cs 3nd dam stores are associated v.~ th

un entity. Wh~n all ~tH itb have be~n d~ tcm1ined. they are placed within an enrity

graph.

ln the third phase, entities arc tran~forrncd into classes. These classes arc

further refined by divtding or combinmg the entiues identified into a set of classes that

balance the leveb 01 al:>strnction with complextr~ or design. This method provides no

iorrnal mechanism for achieving this relint:mem. It is also during this phase that rhe

operanons provided and used by each cl;t~" urc dclincJ. These oper;11ions are identified

by examining the pmccsscs that were in~oqwratcd imo those entities found during the

~econd phase.

Thi~ techniqut. lik.: Bailin\ method dc:S<:nbed above, provides a more fom1al

mcchani~m for object discovery and relin.:ment. L nfonunately. thb method ;abandons

its fonnality during th.: cmcial tirst atld ~cond phas.:s when the processes and da1a

stores arecomhtned ttHO centra! and suppo111ng cnttltes. Ltke many object-oriemed

tc<.:hniques. this method simply provides the use r with a set of guidi!lines for

detem1imng t lt~ types'" abstran ions tltat :m: ho.:>t ' tdted to object-orit:nted

programming.

Object Ons:nts;d Smtcrured Design. It ""'the intention of Wa~serman, Pircha.

:tnd .\lullcr to crcatt: a design methodolngy th;n could be used for both ;~mcmred and

ohject-orientcd progr.mumng [WasscnnanX'l) The re5ult was not~ mech~nism for

performing decomposition but a set of notations for el\pressing decompositions. A

series of object-oriented structure charts are used to express objects, classes, methods,

instantiation, exception handling, inheritance, and concurrency.

Using Structured Design as a base. this method begins with a diagram created

as !he end result of structured analysis and design. This diagram is used to indicate

modules and their interconnections as well as their calling structures and paran1eter

passing. Classes are indicated similarly to processes. To differentiate classes from

olher processes wjlhin the diagram, the rectangles representing classes are modified to

indicate lhe methods defining a class's imerface and its instance variables (figure 2.5a}.

Instantiation is indicated in a similar fashion. Thick arrows can be placed betwet!n

modules ro indicate visibility. a term imended to mean lhat the compilation of one

module depends upon the compilation of another module.

Inheritance relationships are indicated with lhick arrows lhat emanate from the

superclass and point to lhe subclass. In order to distinguish inheritance from visibility,

the superclass's rectangle is dashed (figure 2.5b).

~ posh ~popQ---,1 ( '"'""'!>)

1

(a)

Figure 2.5

-!OO'f

r. ..... -- ---r ..,_ ~ _r: .. du. .>· .... - -- , I · -·· I

!able

' ' . ' ~- - ------------- -~

(b)

Object Oriented Structured Design Example [Wasserman89]

This "method" provides a set of formal notations for describing different styles

of decompo$ition, but it provides no mechanism for object discovery or refinement.

Similar to the CRC cards described previously. this notat ion is probably best used as a

!OOI for other analysis and (lesign methods.

34

~kdified Smtclllm! versus Object·Ori~med Ana!v'j~ and Design

The advanmge' of the modi lied 'tru~wred techniques are easier tO understand

than their potential di,adv::mmges. One <tdva ntagc is that they re4uire little or no

rerrain ing of thO>e ind ividuals who already use them. Another advantage is that many

of them are quitt: fonn:tl and can be used tO va lidate system requirements

[deChampeaux') 11. Thts t' 1mponam 111 large proJeCt,, where diff.:rent indiv1duals are

re,ponsible for the development of component' that must be Integrated into a larger

system. It i~ also tmponam for systems "ho,c correctness and reliability is of a more

en tical nature (Je. life suppon systems, ,urgtcal guidance systems . .:levator conrrols.

heavy equipment contro l systems. etc.). Fommlily is also importam when presenting

analysis resu lts to cli~tliS 111 order to veril'y that the cl ients' or rev iewers' needs have

been met I Liskov751. Th~ potential disadvantages. how~ver. are numerous. Some :l.rgue that object·

oriented programming is a fundamentally different programming strategy !Gibson91.

Henderson9!]. Given that structured techntque' emphasize proce~~s and the

interactions nmong processes. they may ni)t provide the necessary information for

object-oriented progmmming [Bo<x:h86. deChampeaux901. Some believe that the use

of structur<::d t~cbniquc' wtll further di~courage tht- user from addressing the technical

and conceptual uifficulties presented m Chitpter 2. These problems include a tendency

to map procedur;tl ab~rractions directly into OhJ4!Ct ;~bsrractions l 0Shca861 and the

t.:ndency to focus on data rather rh:m on prO<:c's.:' Becki\91. Addirion:tlly, it is argued

:hat :J'JOSL smtctured techniques do not addr~:'' :he 1ssues of data Jb\rraction and

infonnanon hiding and are not responstve co t•hanges in the probh:m space I Bo<x:h86).

~,foreover. few of the modifi.:d ' trucwred technique' address inhentancc. Bas<::d on

these weaknesses. many conclude that objcct·Oricmcd cod.;: produced with structured

Jnalysis and design techniques do.:~ not Jdequ:n..:ly employ inheritance or allow for

rapid devclopm~m and "111 not be ca>ily nuxhtlable or comprchcn~tble [Gibson91[.

It has ;tlso ~em argued :hat objcct·uncntcd orogramming more closely mirrors

the acrual "orld Boochllo. Goldberg~.\ I and th:n •lOJCCt·on.:med tt:chniques are.

therciore. more tntulltvc. caster ro leJrn .• tnd more responsive 10 changes in the

problem dom:un. Rosson. howcvc:r. potnt~ out that no tormal analys is suppons the~e

d auns I Ro~sonl\91. AddiuonaJiv. u 1s :trgtJO.:d that ubject-onemecJ techniques bt!ner

.1dd;ess <he J''uo.:> of cm.:apsulauon c~ntl Jat~t h1d1n~. making code produced with th<::se

tct'hmques .:aster to uncJ.:r,tan<i ;tnd ,tmnlitytng m:untenanrc.

On the 01hcr hand. many have ;~rguc::d th:u purely object-onented analysis and

design ·ech11llJUC' ~~ r:tre .md !h<H thn'c th;u c1o .-"'t are '<!rious!v lackmg tn fommlity

[Wilson88]. Most have no fom1al notation. do not cover 1he enrire life-cycle, are not as

ngorous or comprehensive as their more struc tured counterpans [deChampeaux91,

Lndden89]. Due 10 this lack of fotmalicy. it is impossible 10 val idate systems against

requiremems. Industry standards are lacking on objecc-oriemed analysis and design

techn iques and are, therefore, likely co change. Surprisingly few objecc-oriemed

techniques 3cldress inheritance [Cinss'.>ll. In adJicion. most object-oriemed

methodologies have little to say about r~u~e and usually assume a clean stare when

beginning an ;malysis or design activity [Griss9 11. Because of this, pmemial reuse of

analy~is and design results iS lose.

Another group of individuals believe 1ha1 structured ru1d objecr-oriemed

teclmiques can be incegnued. Because !here are so many different strucmred anal ysis

and de~>ign techniques. il 1s impossible to make general scacemems. Indivi dual

techniques muse be ~xamined [Ward891. Hender;;on and Constantine suggest using

~trict objecc-orie!Hed techniques to determine cla~ses and their rela1ionships and then

developing the methods for those c lasses u~ing structured techniques [Henderson91j.

Seidewicz a11d Stark suggest char smtcrured analysis ~hould first be used co develop the

specification of a syst.:m and then abstraction analysis can be applied co make the

transition to an object-oriemed design [Seidewicz:R6}.

Sqmrnarv

'.t1any claim that the informal ity or ob.J<:Ct oriemed decomposirion methods

prevents them from b.:tng effective for large projects and thar srrucrured analysis and

design techniques should be used. Then! are rwo leveis oi fonnality being srressed in

these argumems. The first .i> a formal ity of nota! ion for expressing the results of

cksign. The second level is the form ality of rh;: n1cchani;;m for decomposing a problem

domain imo a set of classes. While it is true that ~til of the object oriented methods for

tr:msfom1ing the problem domain are informal. claims 1hat process-oriemed analysis

and design technique~ .ll"e more fonnal are " eak. O f chose process-orieme<.i rechmques

invesugated, ~I! fai l to provtde an algorithm for ,Jecompostng a domam imo a set of

process ab:;rrac1ions. What ncufistics they do provtde are li rtle more than advice an(!

:ests which can be appl ied to a candidate decompnsmon. Thts faiiure may not be

acknowledged due to the HU11iiiaruy ot proces~-onented programming. :vlost

programmers are so ll1(1ocmnatcd in >tructmed programmrng that 1hey forget that

decomposition is mherently amhiguous and chat :1 set of rules can nor. in itself, claim co

red uce :t pr<>blem 10 ;J 'llperior ~et or abstraction~.

On the other hand. the Stmctured analysis and design techn iques do appear tO be

superior i n thei r formal ity of expression. Structured programming has existed for

many years and has the bene!lt of numerous formal notations. It seems obvious that

the lack of such formal tools for object-oriented pr<>gramming will be solved over time.

Indeed. the notation provided by Wasserman. Pircher. and :VIuller seems to be a step in

rhis direction.

The fact rhar none of the object·ori.:rneu techniques presemed in th is chapter

adequately udtlresses inheritance or rhe iss.ue of maintenance is, however, a real fai l ing.

Chapter Thrc..::

1!\1-!ERITA:'-!CE .-\~D REL'SE

Inherit:mce i~ a po"'erful mechanism that 'upoons polymorphism. It also

provides the ability to define absrract data type~ tn tcnns of other data types and pl3ces

them within a hicrarCIHcal structu re. This chapter shows that inheritance can be difficu lt

to use effectively due tO conceptual and technK·al problems. It also shows that th..:

re lationship between inheriwnce and reuse is ambiguous.

Open issues related to inheritance and reu'e are discussed in th is chapter First.

severn! potential candidate<. for reuse are idenufi.:d. :\ext. a number of techniques

related to object-oriented programming that help U>l!r.. reuse code are discussed. Thes.!

include delegation. 2cncndtv, confom1ance. enhancement. and inheritance. Inheri tance - - . is then discussed in greater detail. with panicul:tr cmphasi' on the issues that can make

HS effective use di fficu lt. Finally. the advanta~es ;u1d disadval1tages of Stnglc nnd

multip le i nheri tanc~.: ,u-c nut lined.

According to Jones. only 15 percent of new code serves an original purpose

JJonesS4]. :VIany individuals initially approach object-oriented programming with the

expectation that it wi ll resul t in more reuse of code and shonen the development cycle.

While it is rrue that objec t·oriented programming has this pote ntial. there b no

guarantee that more reu>e will occur in the long 1enn. Funhennore, object·oriented

programming does n01 addrc~s many other type' (If reu~. Reuse can abo include code

tcmplat~~ and libr.trie,. Cutting and pasting ..:grncnts of code from one place tO

another can be done, although many argue that tim fom1 oi reuse propagates errors

l Wyl>uh90f. Oth~r~ argue that the design of clas-.; lnteti'nccs sht>lll<l be reused as thev

.trc o ften more importam than the classes. thcm,dv.:s 1Griss9l. Yakemovic90 1. There

arc many prod ucts of analy't' and design that .trc pmenn;ll candidates for reuse. These

include spectficatton>. reqturem.:nts. and diagrar11>. Additionally. the transference of

personnel from project to prnje<:! is a fonn of rcu'e l.\leyer871. The tenn reuse. m the

objec1-orientcd progr:m1ming world. refers 10 a very limited fonn of it~ more general

meaning and only addre~se$ the reuse of code I L..ewis91 ] .

Reuse of Co<"k

There is a great deal of evidence that c>ojecl·orien led programming and reuse

incre:lse producuvity. Lewi~. Henry. Ka1\1r;1. and S.:hulman [Lewis91) conducted a

formal sntdy and round that objecl·oriem~"<.l pr()gr.1mming substamially improved

productivny. The aUihors conclude that a ''gnificam ponion of this productivity was

due to reuse and that object-oriented programming provides for !,rre:uer reuse than

process-oriemed programming. Wybolt <.:1 aim' tha t new software products created

through the mechnnism of inheritance :tllowed ror :1 code savings of 85 percent over

process-oriented solution;, [Wyboh90). Such daims are common although others claim

thm these leveb of reu'e are mre but can be duplic:ucd if rhe prac1ice of reuse is

encouraged [ WoodfieldR7 1.

Ohject-Orientcd vtcebanj~m> for Code Reu~e

Code:: reuse ha~ been sugge~ted as a wny of obta ining faster prototyping through

less work. The follow1ng mechanisms prov1de gremer flexibi lity in the cremjon of

encapsulated emities ba-;ed upon those previously defined and. in implementing the

t:oncept of polymorphi,m. Bmh of the": prm is ion\ can lead 10 grea1er code reuse.

Dds:!Jadon

Delegation ~~ L"'-'d 111 both dass - bas~d and non-c!ass-based object-oriemed

languages. in most languages that >llpi)Ort dclcganon. objecL~ arc defined by stating

how they differ from prototype objects. The prototype objects encapsulate default

behavior. When an object receives a message. it eahs:r performs the requested action or

delegmes a prototype object to accept the; requc\t. D.!leg:trion differs from inheritance m

:har detemlining wh~eh prototype 'nould acecrn a r.:que~LIS a dynamiC process,

whereas inhentonce IS ,mnc. For .::xamplc. 11 :111 <1hject is defined from several

prototypes. each of wil1ch possesses ;tll)ctilt'l<lnamed methodX. an object can decide

dynamically whtch pr0101ypt: shouid I'C\.'civ.: the rcques1. :--Jo ~uch mechan1sm is

.tv~ulaole in mh<::nlnm:c. Some dmm rh:1t <.lelegaHon o.:an smwlmc inhc::ritance bv

dballowing dynamtc de:eg:111on and thnt mhentann: .:annot be made tO ~mulate

delegauon. Lhu~ m;tkin\! d.:legarion th.: more po"'s:rfu l ~-onstruct [ Booch91 a.

39

Licbcnnanl\6. \\'egner~>i. Blair!!9J. While more ll.:xible than inheritance. the use of

delegation may r~>ull•n ohJens whose beha\ ior ''more difficult to predict and control.

G ... ·nericitv

While genelidty is not strictly an objcct-oric111ed technique. it is frequently U>Cd

tn conjunction wuh objcCt·oriemed programmtng language>. Many asscn that it

provides better reu~ability and cxtcndibility. Genencity provides for the creauon of

procedures and methO<.h that can operate on <ever.tl different types of objects. This is

accomplished by speCJ1YIIl£ the "type" of the objects as a parameter to the procedure or

method, allowing it to operate correctly on the other parameters and. thus, simulate

polymorphism. A proposed strength of gencn..:it )II~ that it seeks to remove the burden

of type checking. binding. and behavtor shanng r'rorn inheri tance {Blair89]. It is often

used to make untyped lartguages more robu~t and 'rrongly typed languages more

tlcxibk. :'-.lever anwe' that smce !!enericitv can b.: \!mula ted bv inheritance but not • ... - • i

vtce-\ ersa. inheritance'' a more pov.eri"ulm~('hani'm {~k~·cr86j.

Conformance and Enhancement

Confom1ance ·~a mechanism uM:d in ~om..: c lass-based programming languages

to implicitly derive.: a ..:lass hi.:rarchy and. through enhancement. provide

polymorphi>m. Under this system. classes that "coniorm" to other classes can reuse

methods defined by tho'e classes. A set or ruJ.:., '' used to indicate whether one class

conionns to anoth..:r. -\ .:Ia'~ P .:onforms ;o cia~ ... Q tt' P provtdes all of the method:.

delined by Q. Each method argument anc.i return value derined under P must also

~ontorm 10 those argumems .tnd return valu~~ de1u1ed under the equiva lent method oi

Q. Finally. the arg\tmen ts anLI retu rn v;~l ue' uf Q mu~t confonn tO thQse o f P.

While c:onfom1anc.:e doe~ nm provid~ rrxle 'haring. the addi tional mechanism of

enhancement allows wnt'onning classe~ to indu::ue which .:lass comains the shared

.:ode. When used in combmation. these mecham,m!> 1mpose a class hierarchy and

'lrovide oolymorphbm. For more :ntorm.,uon on thc>e mechamsms. readers are

directed 10 tne work or Blac!-. llutchin>on. L~vy. Caner BlackRil. and Hom

I Hurnl\71.

lnnenrance

lnnentance t~ the !llO>t popuiar mechani>llt ti1r 0<1lymorphism and t:ode reuse 111

class-b;1sed object-oncnu:d programnung language:\. h >uppons the creation of classes

through the "moditicaunn" "other pre~xi"'"~ .;l.r"'"· \lodificarions c:m lx

expansions 3nd/or contractions of pre-exi;ting cl3,ses. This allows users tO "borrow"

attributes und method, from superclasses ~U1d to 111odify those attributes and methods to

~ull the needs of the n~wly defined class without affecting the superclasses.

The hierarchy created through the m.:chanism of inheritance provides

polymorphism because it helps to ensure that ~ubclasses of a panicular class can

respond to a particular message defined under that class. This stem~ from the fact that

classes inherit methods defined under superc lasses. While a class is allowed to

redefine a message, most object·oriemed programming languages do not allow a cla~s

to ignore an inherited message.

Both polymorphism and inheritance have been simulated using structured

pmgmmming language,, Thts is generally done by abS!Tact data types keepiltg track of

amtys of pointers to funcuons. When an abstract d:ua type receives a message, the

array of poimers associated wi th it is examin~d. If the appropriate function resid..:~ in

the am1y. it is invoked. If the function do.:> not exist, a pointer is followed to an

abstract data type that repre,ems a parent of that type and its array of function pointers

is examined. Because this tcl'hnique is prone tO error. few people use it. The

mechnnism of inheritance greatly simplifies this , tylc of prO!,'l'.lmming by removing

from the programmer any re~ponsibility to 1-.ccn track of function and superclass

pointers .

Whv lnheritancs: j, D1fficult

A lthough inheritance hns been used succc~sfully. ir sri II has not provided the

ievel of reuse that proponents originally cl:.limed. \!any novices find inheritance tO be a difficult mechanism to use effectively. There are .1 number of rc3sons why inheritance

j., difficult. These include the following: in:ldequ;ue suppon for inheritance by object

decomposition methods. the contlicr betw.:cn inhenung for delinirion and inheriting for

reuse. the contlit:r betwe..:n inherit:mce and daw hidi ng. the contlict between

general ization and speci;tlization. and a numlx:r of nrher issues onhogonal to obj.:ct­

oricntcd :>rograiTU11ing. Each of these issu~' "111 ~ discussed in the follo,ving

,ection,.

Inadeqqote Suppon for !uhc ruance bv Objeq Dccomno~irion Merhpds

Most techn ique~ for nbjec t decornpo,it ion do nor address inheritance. Tho~e

methods that do provide mechanisms for di~covering or expressing inheritance

relation,hip' are inadetluate Bec:m~ nf tht,. pro;:rammers often attempt tO ascertain

J l

inhemance relationship, u~ing informal and ambiguous methods. This can result in

hi.:rarchies that are difticuh to understand :tnd retN:.

The Conflict Bs:tw~cn lnhcrjtance for Definj tjon and Inheritance for Re use

Two common reasons to us~ inheri tance are at rimes in cont1 ict [Wirfs90aj. For

exampk. a user may ddine a n.:w c lass by inheriting from another class tO reuse the

m.:thods deiin.:d under the pn!·existing das,. The user inherits with less regard to

.. progr.tm s-u-ucture ... ditJerences in cia~~ re~pon!>tbtlities. or levels of abstraction withm

the inherited classes. Reuse of code is the ovemding fac10r in determming from which

classes to tnheriL This fom1 of inherilance IS more frequently found in languages that

suppon multiple inheritance but is also found In :;ingle inheritance exantplcs. ft is often

referred to as inheriting for reuse. Proponcms of this type of inheritance clo.im thai it

max imizes reuse [Meyer~8]. Some point out that this fom1 of inheritance may

encourage subclasse~ that may not be comp;uitole "ith ancestors and may change

method arguments making inherited method' mc.:orrectly ryped (Johnson89]. Still

others argue 1hat the end re,ult of inherimnce for rcu,e is a class hierarchy that is

impossible to understand. m~imain. or reuse. Others assert that inheritance for reuse is

difficult because it is unclear which behavior' or :1 dt~s are .. essential"' and should nor

be rc:clctined among ~ubcbt:.>es [Stemple891.

lnhentancc is mo\t frequently used to indk:atc an is-a relationsh ip between a

new class and a prc-c."sting dass. Here. the purpose IS to inherit the aunbutes and

me1hods from a jpven cia's 10 mdic:ue simtbnt~' b.:tween the two classe~ [ Korwn90).

This is often referred to as mheriting for ddimunn. One viewpoint argues lim coherem

and well structured cla;s hierarchies are the primary factor behind maximum reuse

[Coggins93 J. They argue that the primm)' benefi t of inhe1itance is not reuse, bu t

modularity and underswndabil ity [Micallet'8~J. "hich is more likely to arise from

inheritance for definiuon. Coggins state> that the .:hief contribution of object-oriented

progranuning is n01 reu~. but rat~ing the level of ahstrJcuon implemented in libr.uies

!O a level \\here dienh ,·an dfecuvelv contribute to the destgn of !he soitwa.re th.:y need

Coggins90a). One impli.::uion of this vte" I' thai undue emphasis is placed on the

r<~u>e o r code.

l;nformnately. both ot" these techn tqu~s are J'requently used in conjunction. in

>PiLe of the fan that thetr pnnciples ::tre contradit·tory. The contlict between the

t.:.:hmca.l goal of nKtXIITIIZing reuse and the •·on.:cpwal goat of a creating a conceptually

Intuitive hier.trehy prndu,·c, da,-; hieran:hi<'' that .tre dilliculttO comprehend. Eriksson

suggests splitting the mechanism of inho:ri tance tnto two mechani~ms: one supporting

inheritance for definition. and the other 'Lipponing inherirance for reuse I Eriksson9llj.

The Conl"lict Between lnh~tiram:e and D;u;t lliding

The greatest difficulty in the effective usc of inheritanct: likely ari:.es from the

contlict berw~cn tnhent:tnce and encam.ulatton. Through data hiding, enc:tpsularion

helps create a syMcm thatt> easier to undel'>tand and maimain. Data htding mmimizes

dependencies among cbsses. Inheritance allow' descendent classes to rely on the

implememauon of ancestor classes. :VIany objcct·Oriented programming languages

;tllow descendem classt:s tC> di rectly refere nee instance· variables within ancestor classes.

call private oper.uions on ancestor cl:ts!>es. and refer directly to supl!rclasscs of their

parent classes [Uskovl!71. These abiliu.:s arc what !->ives inheritance irs power. Y!any

feel it is also a liabilit~ . . -\ccording ro 13o<X:h I Boo-:h9ll ].

There i!. a very real rension betY.ccn inheritance and encapsulation. To a large degree. the us.: oi inh.:ritanc.: cxpo~e~ '>Ome of the secrets of an inherited class. Practically. this means rhat to unde rswnd the meaning of a particular class, you mu~t ~tudy Jl! of 11~ :.upcrchr~,c~. ,tllll~tmlC> including thetr in,ide view~.

An is-a re lationship is a "contra..:t" bl:twc~n an ancestor ~nd a descendant. 1l

resrricrs the kind of c hange> the designer or nn ancestor class can make. Renaming,

removing. or rt:interprering an inst:tnct> v:trrable or merhod can adversely affect

descendants [i'vhcallef8!11. :1-lany argue thm ·" cl:t,~es evolve fScharenberg911. making

.uch changes b<:comc, more dit1kuh. -\:, ..:oneep!Ual moditic:mons are made to classes.

rhe ts·a relauonsnip,., IJCtween descend:mt:. 41ld Jnccstors may be altered, causing

unexpecr.:d l"><!havttlr 111 desc~ nden l clas,cs I St..:rnpkR9]. For those whose primary goal

is inheritanc~.: for rc u~e . there is the at.ltlitional b~uc l>f implementation evolution. When

1he reuse of a particular implemenrarion " the primary go:Ji for tnheming from a cl:t;,;.

de~cendent classes may behave unpredk:mbly when that implementation is altered.

Others argue that inheri~ance cornpromt.cs encapsulation by scauering relared

function~ among ance,tors and dcscendanr,. cre;mng unn:ttural dcpendenc1es

1Wybolr1t)J . . \ numb.;r m rules ilavc been prop<>-cd :o help !l111Hnm:e the dependenci.:s

between an~.;~;~tor!\ and dc~c:endtuus Tht~...,\ .. rnh· .. , !_!<:"nerally treat t.U\CC:o.Lors :tnd

de~cendant> .ts unrcilucu classes 111 an an~mpr to lll>n late dt:~<.:endants from the

evoluriottof ancestors. One t>f dte :nore t,;o)n1il1l>ll ,ets of rule~ 1' known ,\S the Ltw of

Dcmen:r. The stronger ver"on <)f thl> ,;tw ,t,lfl'!~ lllat. lor ~II da>scs C Jnd all rnetht)(J'

:1-l :mached to C. all ObJects to which C -.en<.h .t mn~age mu~t be in)tances of the

argument classt:s of\ llincluding Cl nr the ".:wlicit' ins1ance variables of C. This

pre·;enL~ da"t:' :rom din.'C't!y n:ferenclll!; mhattc:d inst.>nce v:u·iablcs. lnste:1d.

Inherited instance variables must be acce~:.cd throu~h methods provided by ancestors.

Thus. if an instance vanabl.: name in an ance>tOr is changed or it is removed tO

dct.:nnine rhe value dynamic~lly, descendaru das>es would not be affected. For more

information, refer to I Lieberherrll8. Liebt:rherr~9 . Sakkinen88. Snydcr86].

D1s: Conrliq Between Gcn>111l iz:Hion and Sm;cta !lza11on

Class nuo:rarch1.:' typocally nave more gcncr.1l das~es 1owards 1he rop oi the

h 1erarchy ami more spcctf:c cla..;ses rowards rhc: bottom. In the construe non or' a

hier.m.:hy. the designer muM fn:quently balance immediare usage needs of a class.

which are usually more ~pcciiic. wi th the more general need of ensuring the ca;e ot'

reuse or that d a$s at a fu!llre rime. Associated rn 1his contli<.:r is 1he conflict between

inheriting a few "large" r.:la,;~es and many "smalld' c;bssc.>. While more general

classes and abstract cl<tss<:s rn:ty be imporwnr on detining imerf.aces for descendants and

easier ro reu-.:. there pou:nual for reuse ma~ 0.: ~mall when compared 10 larger. mo.-.:

~pecific classes. Thl$ j, used as an argumelll 1"1~· 'ome for rop-down design. The

opposing argumenr is rhar more specific cla,~es .Jrc harder to reuse and that bonom-up

design should be used 10 ensure smaller. more general. and more reusable classes. It i~

unknown which technique h~s greater potenrial for reuse.

Dercnnining how general or specific 10 make a class can be difficult. Beck

points out that a minor modification to an ance~10r c.:la>s may eliminate the need for

many descendenr cla5\e~ bur ir may also :1l!er rhe levels of abstraction for a hierarchy

and make it more difticulr to understand I BeckiiXI vl.:y.:r argues that it is impos~ibie

co derect conunonalitic' e:trly ~nough to mo•e them to the proper classes within the

hie rarchy and that d~vdopo:r' n1U>I restgn thcn1\ct,.;, 10 c,.;c:tsional reorganizauorlS of

the hierarchy I Meyer901.

In an dfon to r~,olvt: thts tssue. some h:t vo;: emphasized the distinction between

absrract classes that are oerined solely ro lx ,utx: la,,ed bm are nor insmnriared. and

dasses that are utstanuau:d ht11 never subcla"cd. Orher; ad, ocate abstracr clas\es thar

.m: not instannated. bu1 do ll<lt mstst that tn~tanua~<:d d:~".:~ are not suix:lasscd. These

general classe> .ll'e us.:d a' \:omrac:ts' b.:!"'..:~n lknvea classe> and u:-en; [Rao9:31, Suhcbsses of rhes..: al>,trac.:! ..:l:.t~!'..e~; n1usr fulfill nJl r~ttu ircmcn ts dctlned under rhc

.tbstract da>ses. Many h:tv<.: argued thar ab,iniCI <.: ins;,c~ can be more e:1sily reu~ed and

.1re ot'ren more v;o luabk' rhan rht: 1molemenoa!lon tlll(l~rlyong these contracts l Gris>9ll.

l"ucs Orthogonal to Objec1 Oricmcd Pm!,"ilmming

When object dc:composition and inheritance have been done "properly", or :n

least consistently, •here are ~till a number of issues that can negatively impact the use of

inheritance. These issues were originally rai'ed in the structured programming world

;uld remain unresolved. :vtost object-oriented methodologies never address these

tssues. These include the error hand ling. argument validation. composi te object

handl ing, conrrol and communicat ion. gro up ~nd compound operations, and a number

of "stylistic" issues.

Error Handl ing. Error hand ling refers to how a particular object or process

rc.ponds to errors. There are a variety of ways that an error can be handled and no

single way has emerged :t> the cle;trl} superior method. Although a standard. non­

resumprive exception mechamsm currently elusts m C- +. few languages have

addressed the issue of error handling. Thi~ can seriously limit the collaboration

berwcen classes and the Jmount of reul>t!. Cla,ses may provide for similar levels of

absrraction but employ mcompatihle techn1que~ for error handling, making it difficult to

combine them.

Ar~umem Validjl!jon. Similar to e rror handl ing, argument validation requ ire~

cooperation be tween objects with in a ~ystem. If ohjccts handle argument validation

tlitT~remly, class imeraction may become Jifficult w integrate and prone to error.

Comoosite Ohjeq Hpnd!jqg. Cornpu,i te objects refers to the combination of a

number of objects imo one. Group and compound operation difficulties arise when

..:lasses abstract a domain at different lc,eJs. In Other words. classes m one library mav

embody larger conc.:pts. wh1le classe~ tn anotht!r library may break do" n those larger

concept~ imo smaller ~ub-<:omponcnt;.. While neirher decomposition is incorrect. the

different levels of absrracrion can cause inc:ompa11hilities in ho"· operation;, are

p.:rfom1ed upon these composi te object;..

Conrrol and Cornmunjc;ujpn. Thi" refer' to the gene ral problems involved in

determin ing which objects wi thin a sy>t~m are in conrrol and how communication is to

be established between objects dctin~d in different libraries.

Stvlistic DifferenCe}. Stylistic differences include the level of functionality that

cla,ses mav provide. ortimizarions for ;.f)t:cd. case of use. code or data space

requirements. and debu~ging f;tcllitie,.

For funher informauon on the--e ~~,~~~'- the r.::tdcr 1s referred to the work~ of

Berlin [Berhn90J and Cohen l('ohcn'J II.

Descrimion of lnhemapce Hjemrchjes

l11erc are differem rypes of inherit3nce hicmrchies supponed by object-oriented

programming languages. Tht:se mclude single inheritanc.:/single tree. single

inhcritance/muhiple tree. multiple inhcman<.:c/~ingle rree, and multiple

inheri tance/multiple tree. These last two fonn' of 1nherimnce will be discussed

together.

Single inheritam.:e/~ingle tree i~ a foanll)t inheritance when: al l c lasses are

descendants of a single root class and each d as5 has only one parent class (figun:

3. la). The class hierdrchy provided by Smalhalk is an example of a single

inheritance/single tree. In s ingle inheritanc.:e/mulraple tree inheritance. the user is

;tllowed 10 have more than one inheritance m::.:. In this smaation. each class still inherits

from only one superclass but more than one tn:c exist~. each with its own root class.

The trees remain disjoint (see figure 3.1b). \!ultiplc inheritance allows different trees

to become imenwined by allov. in£ cl:t~,e~ tn anhent from more than one parent clas~

<figure 3. lc ).

Y!any object-oriented languages ~upport all three styles of inheritance. It is up

to the user to decide which foam of inh~rit:lnce 10 employ. Knowing the potentiul co~t'

and bcnd i t> of ~ II three styles will nllow th<.: l"<.:r 10 make an infonned choice when

deciding which style and language toll'~·

Adv;umges and Disadvantage~ of lnhemance lllerarchv Tvpes

Smg!e !nherirance!Single Tree. The pnmary advantages of single inheritance

arc both itS technical and conceptual ~imphCily. A programmer investigating a

particular class em easily detem1u1e a cia~<' ance~tors. making it easier to detennine its

inhemcd behavior and detinition. Thi> ,impli<.:ity .:xtend~ to the definition of objects.

Tcchnacally, single inheritance provides~ mnre \tOib le initial set of anri bmes and

methods wiah which to de tine an obJect. It h not necessary for the user to search

through a variety of inheritance hierarch i~' in order to det.:nnine the origin of a

paruculnr method or attri bute. Conceptu:tl ly. sing!.: inheri tance makes understanding the

puryK)Se of the object ~:aster. The user b freed fr0111 frequendy confusing cases in

which <.:las>c' are defined from the comhin:lllon of conceptually disjoint classes.

The ntO>t obvious di~tdvamage of ,m~k uahem:tnce/single tree environment. i'

Ill at ll mhab11s the use ofhaerarchte~ develop~'tl by mhers .. '\nother problem is that

concepru:tlly unrelated entint:s ma) lx forced antn unwanted relationships. In other

"ord;., clas;.es that encapsulate unrelated entitle~ mu't be placed within the same cia>:.

'liemrchy. Since an inheti t<utce hierarchy unrlie, ·"' i'-a relationship between cbs;.~s

(a) single inheritance/ single tree (b) single inheritance/multiple trees

(c) multiple inheritance

Figure 3.1

Types. of l nherir:~nce

within it. the relationship impued by the hierarchy may nor be valid. If the user is

forced to place the classes within a single tree and does not remember that there is no

conceptual relationship between the classes. an unwanted rc:larionship may develop as

the hierarchy evolves. Although Smallta!k provides some oi the best tools for class

browsing of any object-oriented languagt:. 11 l~ often difficult 10 discover dependenctes

within the hi~rarchy.

Placing large numbers of cl~sses wah in one tree also results in the cre:uion of

libraries that are too large. If all classes must be placed within one tree. the library wtll

become increasingly large :~s i t develop~ from proje::t 10 proJeCt. thus making naviganon

of the hierarchy more difticuh and u:< o i the: hbrary more expen,ive in compu1er and

use r effon.

Another problem caused by placmg wu many cla<ses in one tree is !he in:1bility

to separate applkatiom and tools from 1he environment in which they were developed.

The author and his colleagues enc.:oumered th i~ d iflicuhy whi le developing a

c lient/server project in Smalhalk. It was d~c id~d ro cre:ue 1he cl ient and server modules

within the same hierarchy (image). Thi' was don.: wi th 1he belief that once debugging

was completed. ;he two m<xluks ..:ould he pull~d ;!part and placed within their 11wn

hteran.:hies in order to decre;he tht: ~ize of 1hc h1cr;1n.:hy. While developmg the 1wo

modules within the same h1erarchy served 10 \peed developmem lime. i1 made the

,epar.uion of the modules n<:arly imposstble. h wa, exll'cmely difficult to detenmne

how the code was divided betwe<:n th<: two modules. The "tighmess" of a single -tree

lue rart hy further mag ni tied rhe problems brought abou1 by our poor engineering.

Some members of our group cornpl~Hncd that it was often difficult tO distinguish

between classes developed to suppon tho:: cliem/-.erver modules :111d classes developed

for the tools we had constntcted. Other.; argued that the ~ystem was engulfed by

excessive amounts of unrelat.:d code. The remov~tl of unrelated code was not possible

hecause we did ·1ot know whether l'ode wa' heing u'ed lw the environment it~df. The

developers became concemcd that the remov;1l o r modification of code would break the

'ystem. These phenomena have also b~.:n report<!d by Wirf$· Brock and Wilkerson

I Wirfs88).

Another disadvamag.: involves rhe employment of reuse. Advocates of multiple

inht:ritance argue: that "11£k inheritance c:mnllt ,ufticiemly employ reuse. They argue

:hat ,ingle inhentance 'n01 ,utfictemly tio:xtbk lc>r .:Ia" ,lerimuon and that much reuse

that could be obramed u>tng multiple inhcmam.:e b lost.

Sing!e lnbentaocc/VIultink Tree. One .tc!vamage of ' ing lc inheritance/multiple

rre.:s is rhat the user is free to incO!Jlorale cx t~rnally·>upplied libraries with his/her own

libraries. Moreover. given that not all class.:s .trt: Jcsccndecl from the same c lass. it is

easier to avoid the sHu~tion Jcscnb<.'d in the pr.:vmus ,ection. where the user is forced

to place all. potemiall~ unrelated. cias>e> together 111 one cree. With this form oi

inhentance. <.:oncepw;tll~ ·c!~u.:u avsrr-Jcr~on' .;an l'c pl:!ccd m !heir own tnhent!lnce tree.

Thus. inherimnce can be employed .:xdu,l\•ely to represent valid is-a rebtionshlp>

'mru::r ttnm to impos.: .t srru~mre on unrc!at~d ..:Ia s'o::s.

An addi tional rechmcal advanta!!e l)t' ,111~ 1.: tn helitance/muluph.: trees ts that

111divtduals on a dcvdoomenr team can he r~~potNiliC for d ifferent inherimnct: rrees.

Tht' can elinunme much oi rhe .;oncern that ~.:hangc' mad.: by :111 individual pro!,rrammer

ma~ tnadvenemly re'uh 111 ,·hanges in the ddintn<>ns oi' mner classes.

One db:tdvantage of muhiple rrees b that determining relationships between

classes is more difficult. With multiple tree>, a u,er c:uuJot assume common ancestry

ror different d~~ses. The behaviors and imeraclions of c lasses that belong to different

trees may be rnorc difficuh to detennine.

Multjple lnhclimnce. One advantage of multiple inheritance is increased

t1exibility. :VIultiple inhemance does not cono;train inheritance to one parent class. Thts

may be beneficial if the user desires to inherit a numlxr of atttibutes and methods from

different. even unrelated. dasse~. A user can inherit a particular atttibute or method

from any number of pre-existing classe' and avoid the duplication of the code

necessary to implement the au:ribute or m~thod, with in the newly defined class. In this

manner. multiple inherit:mce can facilitate the rcu~e of code (Linton87, Borning82j.

Moreover. others argue that it allows the u'er to remove a rigid. hicrarchic:tl view of the

world that ~ingle inheritance impose~ [Wirf~xx . \leyerl\8 ).

Although multiple inheritance~~ irequently used for inheritance for reuse. it can

be used to inherit for detlnition. This can occur if a number of related entiues canlx

divided into two concepru;tlly overlapping group,. Coad and Yourdon give the

example of plane~ (figure 3.2). In thts cx<~ntple. the dass Plane is subclasscd into two

groups: type of craft and use of craft. Type oi' craft can be either jet or propeller, while

use of craFt cnn be either civilian or mrluary I Coad91 aj. Another proposed advanwge is

that multiple inhentance encourages m<Xlulamy hy allowing classes to be built from a

variety or cornpon~nt dasses [\loon861.

The~e are a number of disadvantage' of multiple inheritance. One of the mos1

difficult problems is that of add itional ce>mplcxi ty This may occur in a variety of

ways. First, there i:. th<: technical problem involving inheritance from two or more

c lasses which have a merhod or instance variabk name contlict fCarre901. These

dashes occltr whencwr a descendent clas)o. is dcfinc:d as mheriting from :ulcast two

classes. where each ha' a method or instance vanable with the same name. For

example. a das~ C rntght inherit from the dt"e' A and B. each of which has a method

enritled mcthodX. When cl~t's C i< deli ned. the 11'er must d.:tennine which method.X

~hould be inberit.:d.

This J)robi<:m b typically handled !'rom a technical. rather than conceptual.

standpoint by most object-oriented programming l:tnguages. Some languages force the

user tO rename at lenst on.: of the offending methO<b or instance v;~riables. 11tis

n~ce~imte~ the moditic:uion of descendent cla'sc' t:ven though their mterfaces may not

have changed l ~leycrXX. :1-licallefliR 1• \\'hen anrihtnes or methods arc renamed, it can

become difficult to find particular behaviors or ntcibUies. because the user is forcc:d to

create new names that are less imuitive than the original names.

;.. rcrat:

1

Mlltta.ryAm:ratl Q .. ,.MnAJtc:-att JetAJrcrafl ?'ooA.Ireran

J.. A

r . - - . - . - -~· . . -Md<Wy.JeV,oet•ft Mdotary~h CMoan.JOIAitcraft C•VII•a,ProaA:fCtar.

-Figure 3.2

:-.1ultiple Inherita nce 1Coad91aj

Some languages require the user to specify the orde; in which ancestor classes

are inherited so thar the appropriate method is detennined. With this method, classes

may behave differently if the specified order of inheritance in changed in any ancestor

c lasses, even though the descendent class' interface has not changed. This method has

the additional problem that it does not suppon situations where two or more ancestor

c!:~sses have multiple clashes and the descendent class requires default methods or

instance variables from one ancesror and some from another ancestor. Users must also

remember the order in which classes are inherited. which may not be intuitive and,

some argue, violates encapsulation.

A third group of languages require the user to specify at i nvocatio n lime which

of the offending methods should be used. If evolution occurs, all three methods force

the user tO change the tnten'ace 10 one or more classes. Changing the interface of a

class often requires changes to other classes that interact with it. Thus. multiple

inheritance can require the u~er to sp-:nd addHionaltime on code maintenance and may

rn~kc clean enclpsulallon more difficuh tn ;tdu~'''·

Problems ~bo an$e when mulupt.: p:uhs exist between two classes. This is

known ~s repeated inheritance and c:au$e\ different problems for different languages.

Such case~ generally require language sp.;cific solu tions. Becau.sc the problems and

.-olutions of repea ted inheritance an: lungut1gc-sp.:d fic, this chapter does not address

thi' issue. For more infommion. refer lO (Cargill90, l'vleyer88. Booch9la(.

Anoth~r ditTicuity mvolves detinition. When writing or mauuaining cooe. 11 is

unponam to underst:1nd whm a dass n:prc,cm, . .\luhiple inhentance can make 1h1s

rask more difficuh. Docs lhe ;>roposeo abstracuon differ from all other ennnes ro rhe

~xtem lhar it must be descnbed by 1wo potenually unrelated classes? What arc the

implications of using multiple inherimnce to borrow behavior from porenrially unrelated

c lasses? How cun thi$ ai'f~.:t our comprehen~ion of a panicular cla~s·?

The most serious disadvantag.: of muluplc inheritance is ~harcd by single

inheritance. Given that every class within a hierarchy depends directly on all ancestors

for detinition and implementation, any modific:uion of ancestors may change the

b.:havior and detinition of all descendant<. With multiple inheritance. this problem is

magnified due to the exponential growth in the number of inheritance paths between

ancestors aud descendants. :my one of which may affec t descendent classes. Si nee

classes may be detined much funher down the inheritance hierarchy from a modified

ancestor class. the user may remain unaw:m~ of the:: modifications.

Cargill points om that the use of muluple inheritance is fairly easy to avoid

(Cargill90]. When the inheritance of methods or anribute, from a number of parent

classes !S desl.l'cd. one can :nhe:-~t directly from one parent clas~ and place within !he

nc::w class attnbutes "hose values :Ire tn't:mce' <\f c!ach of the other "parent" classes.

Thus. the new cia~:. bl'c:Omcs .1 composne .:l;t". :\ccess to the methods and auribme,,

o f the addition:1l ''parem" cl~s~e~ c:an t->~ ohwin.:d through the use of [he arrribmes in the

newly created cla~s.

If the u~e of multiple inherit:ln<.:<' IS tor derinition r:uhn than for reuse. the

rc:chnique outlined above may create .1 da:-.., rh;u i, less comorehcn:.ible than a class

.:reate<i us1ng rnuluple mhenrance. For c::xample. 11 a user w1slle; 10 create a du,,

Cyborg by mhenung from l'ias' .'vl:m nnd ..:l.ls' Rohot. pl~cmg :m 1n;tancc of class

Robot ins1de an msrnnce of class :vtan <.:Oll id 11.: v.:rv contuswg because 1t sets up a p~n·

ot' rdauon~lnp when :m 1s-a rei:HJOnsn1r I'- more c:onceptuatly sausfying.

Mult1olc mhenmnce ~~ . !.>y dctimunn. more tlex ihie than ,mgle inheritance. 11

allows u~cr> to tr<:cly 1nh.:m rrom an~ cia''· Vl:my argue that it came~ immense

pmemial for nHwse (Hende~on91]. Jm.l '(>me .1rgue !hat most .:xamples of multiple

inhemancc: n the litcr.nur.: are .:ontnv<."<.i !Enk~~nn<)O I or rndicarc an error in analyst'

51

and d.:~ign [Cargi1190J. li><:~ must give careful con~ider.nion to the use of multiple

inheritance, wetghing l'0~t> agam~t benetits for ea<.:h s11uauon.

Summarv

Classes an: the m.:chanr:;m thm 'uppon t:ncapsul:uron. The need for

encapsulation na~ gro" n out of many y.:= or ~tn•ctured progr.;mming expenence. As

such. the goals and advantages of .mc~pwlauon are well-understood. Inheritance is a

mechanism that support> polymorphism. Like encapsulation, polymorphbm hal. abo

grown out of a programmtng need. lt allow> newly created abstract data types to reuse

unm(x! ified cod~. Without polymorphi~m. code (lften requ ires large sets of condi tional

swternent~ that test th<: type of an object and :.:al l the arpropriate function. Every ume

an ab,rract data rype i:; created, a new condittonal must be created.

The mechani~m of inheritance. however. h:1s not grown out of a well­

understood programmmg need. Ahhough 11 'uppons polymorphism. inheritance also

wppons the definiuon of abstract data tvpes in t.:rms of other data types and places

them within a lu~rarchy, ;tllowmg the reuse of code ckfined by ancestors. While this

ability is powerfu l, there :•ppcars to be no cc:>n~cn~us on what fu ndamental problem of

programming it wa~ created to solve. What prol)lem does this power address? What

an~ the implications of defin ing one clas:. in tcrm~ of Others and placing classes within a

hierarchy of shared code? It is as if inheritance v.t>re some stmnge item discovered 10

the :unc and for which everyon~ i:. now dam1mg to .mo" the proper use.

t;nlikc encap>ul:mon and polymorph•>~n. the goals and advantages of

tnheritance are uncle:u·. Because of 1his. 11 ts explored !rom the opposlle direction. The

end resu lis of its ttse are examined fi rsr and then :111 :!llempt !O sunnise its funCri\)ns ;tre

made. This confusion can be s~cn m tne .lrgtllncnr' over 'inglt: and multiple

mhenrance . .'vlo>t of these: arguments con,ist pnmanly of end-result advantages and

di,aclvama!!es of the mcchamsms rather than the theorv underlvine them. - ~ . --Th:-ougn all th1~ .:ont'u~iun over the pnnnnlc' hehmu inheritance ..:om~:. those

;;ra,ping the banner or .;ode retbc. Rcu><: l)t .:od.: ., Jn extremely imponant goal but

u~ing mherimnc:.::. "tnctl~ ror ....:OdL: reu~c n1i1Y oc I ilo..c U~tllg a ~hutgun to hum flies.

While it can b<5ll,\:d. 11 may not b<:: dfective wnhollt proper guidelines. Add itiona lly. it

provides a great de:tlmOr\: power than tnc rt:u>c nr code. Understand ing th is power

,tnd le:1m1ng how best tn ,tpply H :tre •mer<::,llll!; t.."h:llkng<!s.

.5.:

CONCLUSION

In di~cU>>ing the issues of learning obje<.:t-onemed conceptS, objt:et

decomposition. and inhemance and reu:-.e. a numlxr of questions have ari~en.

The first issue was vocabulary. There are a multitude of terms in the literamre

used to describe similotr concepts. Addi tionally, mony of them are used to describe

multiple concepts. This makes deeper di~t·ussion of some issues d ifficult.

Another issue wa' kaming the ba~i<: concept' of object-oriented programming.

Learning from ex pens ,ccnb to be a umver,;tlly accepted idea even if no o ne knows

ho" to do it at tht~ time. h seems apparent th;u ,ome son of language independem

sening can lx helpful. e'pecially in helping the: user distinguish berween languages and

language pnnctples. h i' also importam that academia and industry take a more

aggressive role in tt:adung the whv of programmtng rather than j ust the~ of

programming as they have. tr:ldi tionally done.

There is a great need for evaluation 1>t' th~ df.:ctiveness of object-oriented

analysis and dcstgn techmques. Why arc thc'c techmque-; so infonnal'! Doe~ this tell

us something about thr: namre of progr:unnlmg'! Why don't more of rhem properly

address the issue ot' inheritance? Wh) don't more ot' them cover the software. life

cycle? How can the•c infom1al technique:. po,sibty be u~ed on projecrs involving 10.

50. or 200 people'? Can ~rrucm red techniques be imcgrared with object·oricmed

techniques? Should thq? If object-oric nLcd rrogrammi ng is supposed to prov1de for

c:a;ier reuse. why aren't there: more obj<:ct-b:bcd libr:~ries available'? If they arc

available. why aren't more people using thc:m! ~kthodologies that cover the entire life­

cycle. especial!~· th.: most lengrhy. exp.:nM\t:. and overlooked pha~ of maintenance.

must be developed to .ud developers in hier:trchy construction and maintenance. Object

oriented analysb anti oestgn .:annot ha'~ :1 stgnirlt::tnt impa<.:t on >Oft ware consrruction

unnl these is~,ut:~ arc n;.~.olved.

lt h;1s been cla im.:(! that tho:: two most impon.am contribu tions of object-oriented

r rogrammmg are CllC:IJhUiatinn ~nd inhaicnncc. Encapsul;nion is ;L principle whose

u~fulm:~> 1~ .:.t~ily !,!r:bp<:d even if its .:ft.:c11vc u": is more elu~tve. Inheri tance. on rhe

other hand. i~ not a pnnciplc. It i, a n~echatH'm that is used ro atd in the definition of

.:miry a~trJC!Ion' 3nd 111 :h: reuse of c<Xk. Th~'e goals are often commdicrory.

:Vlechanisms like delegation and generici ty rh:u s.h<tre some of the same goal s as

inheritance should also be examined more thoroughly for their usefulness and power.

-ll1e desi re to i nheri t for reus~ and defini tion has nor been resolved. Are these two

different mechanisms'! Is one better than rhe other''

The type of reuse provided by inheritance and other mechanisms in mosr object­

oriented languages is only one kind. Js it real ly fair to expect objec t-oriented

programming to help in the quest for reuse when most of the techniques availabk are

rhe same techniques that have been available (and ignored) for decades? It seems

unlikely. :-.!e ither a philosophy (l ike object-orientation) nor a language mechanism (l ike

inheritance) can overcome i rs poor use by a programmer.

Finally. rhe questions surrounding multiple inheritance are numerous. with

passionate proponents on both s1des of the issue. Whether or not multiple inheritance

is eventually judged good or had :>eems 111001. I ~ is here now and is being used by

many. Perhaps more research should h~ done on how rouse i1 effecrively in order to

limit its disadvantages.

The Furure of Structured and Objeq-Oriemed Programming

Object oriemed programming mremprs ro solve many of rhe problems

discovered in structured programming. It provide~ mech3nisms superior to mosr

srrucrured programming languages for higher-level concerns such as encapsu lation and

reu$e. Tt does not. however. address any of the l.ower level issues that have plagued

structUred programming since its inception. Error handl ing and va lidadon of argumems

are exan1ples of lower-level design decisions rhat are not handled well by either

method. Because it does nor address these bsues. obj ect-oriented programming. by

itself. will not provide rhe levels of reuse that many have ctaimed.

Some have suggested that the fumre of programming languages resides in logic

programming, funcrional programming, knowledge-based sys tems, multi-paradigm

systems. and many or hers. The competing concerns of ef ficiency, understandabi lity,

and tl ex ibility will most likdy prevem any one bnguuge or methodology from replacing

ail of the others. As the computing commtlllity expands and becomes more integrated

through netw(n ~s. tht: r~<::<:ti rm touts thm suppon distributed. asynchronous compming

becomes more imponanr. Objecr oriemed programming languages are notoriously

weak for dealing wi th asynchronous comrnunic:n ion. While some research is being

done 10 overcome this weakness. standards remain d isram.

As lower-level issues are addressed and [he needs for inregralion, effic iency.

undcrstandabi lhv. and llexihil iry are 11nderstond. ohje<:l -orienrecllangunges wi ll most

likely splinter 1nto numerous groups. <!3t:h "ith their own set of solution~ to the

problems at hand. The concepts th:u underlie object-oriented programming will

undoubtedly become iucorporated into ftlture programming methodologies.

55

B ibl iographv

[AbboH831 Abbou , R. J . Program design by infom1al Engl ish descri ptions. Communications of the ACM , 26(11). November 191\3, Rl\2-894.

lAmebi90l Antebi, M. Issues in teach ing: C+-'-. J oumal of Obje.ct Oriented PrO),'Tamming. 1\clvember 1990, ll-2 1.

fBaii in89 j Bail in, S. C. ,.l,n object-orien ted requirements 'pecifica1i0n method. Communica tions of 1he .ACvl. _n(5) . May 191\9. {,()8-623.

I Beck86l Beck. K. cornmems made by K. Beck during panel session Pane l: the leamability of object-oriented pro1,'Tamming ~ysterns. OOPSLA conference proceedings. Septembe r 1986, pp. 501-506.

fBec k88) Beck, K. Raghaven, R., Lalonde. W . R., and Weinreb. D. Pane l: experiences with rel!sability. OOPSLA conference proce.:d ings. September 1988. pp. 502-506.

[Beck89] Beck, K., and Cunningham. W. A labOnliOry for teaching object-orie nted th inking. OOPS LA conference proceedings. Ocwber 1989, pp. 1-6.

I Berlin901 Berlin, L. When objects coll ide: Experiences with reusing multiple class hierarchi~$. ECOOP/OOPSLA conft:rcnc.:. proce<:dings. October 1990. pp. 1Rl - t93.

fB lack87] Black A., Hutchinson, !\ .. Ju l. E .. Levy, H., and Caner L Distribution a11d absrract types in Emerald. IEEE Tran:;ac1ions on Sothvare Engineering, SE-13 (1 ), January 1987.

fBlnirS9] Blair, G. S., Gallagher. J. J., and Mal ik. J. Genericity vs inheri tance vs dele!!Otion vs confom1ance vs .... Journal of Ohit:ct Oriented Pro!!ramming, September/October 19)(9. l !- 17. · · - -

[Boochl\3] Booch. G. Softw:tre engineen ng wi1 h :\ da. Benjamin Cummings, 1983.

[l3oochSI'lj 13ooch, G. O bjecr·onentecl development. IEEE Transactions on Software Engineering. !2(2). Febmary I ')1<6. 5- c 5.

fBooch9la]l3ooch. G. Objec t-onemed design with appl ications. Be njamin/Cummings. 199!.

[ Booch91bl Booch, G .. and Vilot. M. ObiecJ ·nrknred anal vsisand desi!!!l. The C++ Repon. 3(8), September I y() I . 7 · I 0. ' -

I B0rkoles901 Borkoie~. J. A flare for tht dramntic- Actor .\0. London Univer$HV. UK. EXE UK 5(6). >i•lv.:mbt:r l<.l'.lO. pp :::o.:::} -::.J,:::(}. •

Borningi:\21 B<Jrn ing .. A. H .. •md Ingall s. D. H. H . . 'vlulupie inhemance in Smalltalk-~0. Proceedings or til.: :-Jauonal (\mkrt:IK't: Prl _-\nrficwllnrel ligence, 1982. pp. 23-1-~37

I Cannoni:!O I Cannon H. I. Flavors. Carnbnd!!<:. \ ·IA. :VI IT M tificial lmelligence L.rborarory Technical Re pnn. 1 9~0. - -

56

[Cardell i91 1 Cardelli . L .. Donahue. J.. G lassm3n, L. , Jordon, M., Kalsow, B., and 'ie lson, G. Modula-3 l ~ngu:1ge defini1inn. SIGI' I.AN !'iotices, 27(8), August 1992. 15 -42.

l Cargi ll9()] Cargill, T . A, Does C++ really need mult iple i nheritance? 1990 U SE NIX C++ conference proceedings. 1990. pp. 3 l .'i-323.

[Carre901 Carre, B. The point of view no lion for multiple i nheritance. ECOOP/OOPSLA conference proceedings. 1990. pp. 312-321.

[Coad9 la) Coad. P., and Yourdon. E. Object oriented analysis. Yourdon Press. 1991.

[ Coad9lb] Coad, P .. and Yourdon. E. Object onented .design. Yourdon Press. 1991.

[Coggins90a] Coggins. J. M. Designing C++ li braries. 1990 USENIX C++ conference proceedings. 1990, pp. 25-35.

[ Coggins90bl Coggins. J . :vi. Leuer~ to the edi1or. C++ Journal, F:ll l 1990, 54-60.

(Coggins93] Coggins. J. M. Practical principals for library design: Selecting the right abs tractions is 1he key. C~+ Report, February 1993, 38-42.

[ Cohen9J'I Cohen, B .. Hahn, D., and Soiffer. N. Pragmat ic issues in ilie implementation of flexible l ibr;tries for C+"-. USE:--.I IX C++ conference proceedings. 1991, pp. l93-202.

[Copl ien91 1 Coplien. J. Experience with CRC Cards in AT&T. C++ Repon. 3(8). September 1991, 1-6.

[Cox841 Cox. B. J. Message/object progr;nnming: An evoltl[ionary change i n programming tec:hnologv. 1 EE£ Software. I (I). J ~ nuary 19R4, 50-69.

I Cunningham861 Cunningham. W .. and Beck. K. A diagram for object-oriented pro:,.,-ams. OOPSLA conference proceed ings. 19Xo. pp. 361-367.

I Dahl70] Dahl. 0 . J •. Dijkstra, E. W .. and Hoare . C. A. R. Stntcwred programming. New York : Ac~demic Press. 1972.

l'dt:Champeaux90] de Champeaux. D .. Con>.tantine. L .. Jacobson. !., Mellor. S .. Ward. P .. and Yourdon. E. Panel: StnJcwred an;llysis and object oriented analysis, ECOOP/ OOPSLA conference proceedings. Octol><:r 1990. pp. 135-139.

ldeChampeaux9l ] de Champeaux. D .. America. P .. Coleman, D .. Duke, R., Lea, D .. and Leavens. G. Fonnal tec hniques for 00 software development. OOPS L A ..:onference proceed ings. 1991 . pp. I M - 170.

ldeChampeaux921 de Champeaux. D .. and Faure. P. A comparative study of object­onemed analysis methnds. Journal of Ob,icct Oric:med Programming, March/April L992. 21-33.

I DeNatalc\101 DeNa mit;:. R .. La londe. J.. Leathers. B .. and Phi l ips, R. Panel : OOP i n rhe Real World. OOPSLA/ECOOP conference pmceedings. 1990. 29-34.

57

[Oijkstra68) Dijksrra. E. W. The structure of the THE multiprogramming system. Communicanons of the r\C\<1, \<lay 1968. 3~ 1-.~~6.

1Eriksson90] Eriksson. M. A correct cxampl~ of multiple inheritance. SJGPLAN Notices, 25(7), July 1990. 7-10.

[Fichman92 1 Fichman. R. G .. 11nd Kemerer, C. F. Object-oriented and conventional J nalysis and design mr:thrn.iologi.:': Compuri,on ,1nd critique. IEEE Computer. O<:tober !992. 22-39.

I Fontana91 ] Fontana. \I.. and ;-\eat h. :-.1. Chec~ed out lnd long overdut:: Experiences in the design of a C++ dit'' library. t:SE~lX C..-- conference proceedings, 1991. pp. 179-19!.

1Friedman9l ] Friedrn;ul. L. Comparative progr;unming languages. Prentice Hall. 19\l I.

(Gibson911 Gibson. E. Flanening the learning curve: Educating object-oriented developers. Joumal ol Object Oriented Prol;r;unm1ng. February 1991, 24-29.

1Goldberg83] Goldberg. A .. and Robson. D. Smallt;llk-80: The language and ns implementation. Addl,Oil· Wesley. 1983.

1Griss91 ] Griss. M. L .. Adam,, S. S .. Baeqer, li. Jr .. Cox, B. J., and Goldberg. A. The economics of <ofrwarc reu~e. OOPSIJ i ron l'crenre proceedings, I 991, pp. 264-:!70.

1 Harrison89] Harrison, W II., Shilling, J. 1.. and Sweeney, P. F. Good news. bad news: Experiences building o software development ~nvironment using the object· oriented paradigm. OOPSLA conferem:<! proceedings. 19R9, pp. 85-89.

I Henderson91] Henderson-Sellers B .. and Con:.tantine. L L Object-oriented developmem and functional decomposition. Joum;tl of Object Oriented Programming, January 199i. I 1·16.

[Horn87 1 Hom. C. Conformance, genericity. inheri tance. ;md enhancement. ECOOP/OOPSLA conl'crcncc pmcc:eding,. June I 9X7.

[Johnson89] Johnson. R. comments made by R. Johnson during panel session. Panel: Lnheritance: Can we have our cak~ ;md ~;It it. too> OOPS LA conference proceedings. October 1%9. pp. 486-.!'.Xl.

1Jone,841 Jones. T. C. Reu,ability in progr..unmmg: A ;urvey of the state of the an. IEEE Tr.tnsaction:. on SoftwJre Engu1eenng, Sl'ptcmber 19ll4.

1Jossman90] Jos:.man. P. R .. Scli i.;lxl. E. :--1 .. a nd Shank. J. C. Climbing the C-n­le:ml ing ~.:urve. USENIX C++conl'ercn<.;t: prtll'co::d ings. 19<,)0, pp. 11-23.

!Kempf87] K.:mpf. R .. and Stelzner. !vi. Teaching object-oriented programming with ;he KEE system. OOPSL.\ <.:on ferencc prol.'c~dur~~- J'.)X/, pp. 11·25.

I Korson901 Kor.-.on. T. and McGregor. J. D. Understanding object-oriented: A umfying pamdigm. Cnmmtuuc~tio•h of th.: ,\C'\1. }~(9!. Seprember 1990, ~0-60.

[Korson91] Korson. T .. Hazelrine. :\ .. Hilgenberg, T.. Philip. R .. and Taylor. D. Managing the tr:1nsition to object oriented lechnolngy, OOPS LA conference proceedings. 1991. pp. 355-35R.

fLadden891 Laddcn. R. M. A survey of i~sucs tO lx considered in the development of an object-oti~med development methodology for Ada . . >\da Letters, 9(2). March/Apri l 1989. 78-8~ .

[Lec91] Lee. S .. ;md C.trvcr. D. L OhJec:-,mcntctl analysis and spectfic:ttion: A k:lowledge ba'c approa..:n. Journal o!ObJL'<:t Ont!med Programming, January 1991. 35~3

1Lewis91] L~wi~. J. A., Henry. S . .\·1., K.tiurJ, D. G., and Schulman. R. S. An empirical ~ntdy of the object-oriented par3digm and ,oft ware reuse. OOPS LA conference proceeding>. 1991. pp. Jl\4-196.

[Lieberherr881 Lteberherr. K. L Holland. 1 .. and Riel. A. Object-oriented progrmnrmng: An ObJCCtive ~ense of style. OOPS LA conference proceedings. September 1988. pp. 323-J:\-l.

[Lieberhcrrll91 Lieberherr. K. J .. and Riel. A J. Contributions to teaching object­oriented design and programming. OOPSL.A .:ont'crcnce proceedings. 1989. pp. ll-12.

I Lieberrnan86J Liehem1an. H. Using prototypic:JI objects to implement ~hared behavior in object oriented ~ysrems. OOPSLt\ conftrence proceedings, September 1986. pp. 21-1-223.

1 Limon87] Linwn. M. A .. and Calder. P. R. The design and implementation of InterViews. Usenix C++ Papers. 1987. 256-267.

[Liskov75] Liskov. B. H .. and Zilles. S. \1 Specificmion techniques for data ;!OStrac:ion. IEEE Tr:ms:tc:ions on Softw.trc Engmcering . .\>larch 1975.7-19.

1Liskov87] Ltskov. B. H. Data abstrac;ton and ht<.'rarchy. OOPSLA conference proceedings. Octohcr J!hi7.

I McKenna~8 1 Mc Kenna. J. comments made by J. McKenna during panel sess ion. Teaching OOP. OOPS I .. A conference rnx.:e~ding,, September 19X8. pp. 386-387.

l.\1eycr86j Meyer, B. Genericiry ver.u~ inheruanc·.:. OOPSLA conference proceedings, September 19R6, pp. 391-.JO;'i

I Meyer871 Vleyer. B. Reu,~biiiry· The c:;t"' fnr •m•ec:-oncnted de~tl!n. IEEE Software. \larch 19XI. 50-().1,

llvlcycr81lllv1e;ct. B. OIJJ<::<:t·oricntcd '(l ttw;m: <:othtrucuon. Prenuce llal l. I9Xl\.

1.\lleyeril)j .\lleyer. 13. Tools for rhe new cul1urc: Lc,~ons from the design of rhe Eiffel iibr:mes. Cu111mumc~tions ot' the ,\C:\1. nt<h, Septe:noer 1990. nt).::J8.

1Me~·cri3] :\ley.:r. B Pe:>onli corresponde:ll'C, 1993.

(:-licallef88l :.Jicallef. J. Encap,ulation. reu-abiluy and extensibility in object-oriemed programming language,. Journal of Object Onemcd Programming, April/May 1988. 12-36.

[ Moo91] Moo. B. comments made by B. Moo during panel session. Issu~:s in moving from C to C++. OOPS LA conference proc~cd i ng~. 199!. pp. 163-165.

f'vloon86l :Vloon. D. -\. Ohject·nriemed ;>rngramming '' ith Flavors. OOPS LA .;onierence ;:>roceeding,. l 9x6. pp. 1-x.

!0Sh~861 O'Shea. T .. B<:t:k. K .. Haiben. D .. ..1nd Schmucker. K. Panel: the kamability of object-oncnted programming >)l~tem,, OOPS LA conference proceedings, Septcmb..:r 19~6. pp. 50::-506.

10xford86] Dictionary of .:ompuring. Oxford Umversity Press. 1986.

I Parnas7:!al Parnas, D. L. On the criteria ill 11<! used in decomposing systems into modules. Communic;uton' nf the ACM. l 51 12 ). December 1972. 1053-1058.

tParnas72bj Parna,. D. L. A technique for 'othv;m: module specification with examples. Communication, of the AC\ I. 15t5J . .\lay 19n. 330-336.

[Pugh88] Pugh. J. commems made by J. Pugh during panel session. Teaching OOP. OOPSLA confcrenc.: proc.:cdings. Sep1emhcr l9KK. pp. 3!16-387.

[ Rao931 Rno, B. R. C++ anci the OOP J);mtdigm. :Vl\:Graw-Hill, 1993.

1 Rosson89j Rosson, M. B., and Gold. E. Problem-solution mapping in objec t­oriented design. OOPS LA conference proc~edin g,, October 1989. pp. 7 ·I 0.

I Sak.\:inen88] Sakkinen. M. CommenL~ on "the: law of Demeter" and C++. SIGPLA:\ '-'otices. ~3( I : ). Dece·nbcr 19!1!1. 31!-.l.l.

I Sandberg86] Sandberg, D. W. Smallwlk and ex1>loratory programming. SIGPLA:\ '\mices. 23Ci0). 198(>. ~5-42 .

I S:tunders89 1 Saunder,. J. H. A survey of ob,i~<.:t·oricn tcd programming languages. Journal of ObjeCl On.:mcd Programmmg. :Vlardt/1\ pnl 19X9, 5- 11.

I S.:harenbcrg91) Scharenberg, M. E .. and Dun;more. H. E. Evolution of classes and objects during object-oriented design and pmgramnung. Joum:ll of Object Oriented Prognmming, Januarv lll<ll. 30-34.

Sedbrook90] Sedhrook. i' lmprt)vi;auonal .:xcrt:t;,c\ lor hatchmg Oi:JjeCtS. Journal ot Ohjct:! Oriented Prngr;unmtn~. '\,wemh<:r ( Ill!(), JO-.J:

S~: idcwirzR6] S.:id;;:wi!Z. t:. ... tnu Stark . ,\11. l"nwarrls a general ohject·orietHed ~oft ware developmenttnctlmdology. Prot:ecding, (>I' the Firsr [mernational Conference

>11 • \da Programnung L;u1guag<= Appl ic:uion;, tor tile NASA Space Smnon. l9l!6.

1Sh_aw84 j Shaw.:-·!. \bmaction techntquc' 111 lllll(it:rn programmtng languages. IEEE Sottware. October ll)XJ. 10<!6.

[Shilliog89J Shilling. J. J .. and Sweeney. P.r. Three steps to views: Extending the objec1-orient~d paradigm. OOPS LA conrercm:e prOCt!edings. 1989. pp. 353-361.

[Shlaer88] Shlac.r. S .. and :vlellot. S. J. Object onented systems analysis: Modeling the world in datil. Yourdon Press Comi)U!Ing Series. Englewood Cliffs. NJ, 1988.

[Snyder86] Snyder. A. Encap-sulation and inheritance in object-oriented programming languages. OOPS LA conference proceedings. September 19R6.

[Sincovccl\-1[ Sincovec, R. F .. and Wiener. R. S. \llodular software construction and object-oriented design using Ada. Journal of P.l~al. Ada & :--.todula-2. March/April 198-1. 30-36.

[Stemple89J Stemple. D. comments made by D. Stemple during pand ~ession. Panel: lnhe.ritance: Can we have our cnke and ea t i1. too? OOPS LA conference proceedings. October 1989. pp. 486--190.

[Strousrrup84J Strow.mtp. B. Data abstra<.:tion tn C. AT&T BL TJ. 63(8), October 1984. 1701-1732.

[Stroustrup8S) Strousmtp. B. What ts object·onemed programmmg? IEEE Software. 1\lay 1988. 10-20.

[Ward891 Ward. P. T. How to imt:grnte objec1 nrt~ntation w11h structured analysis and dt!sign. IEEE Software . .Yl<lrch 1989. 7-1-X~.

[Wassennan89J Wass.:nnnn. A. 1. , Pirchcr, P. 1\ .. and Muller, R. J. An object­oriented structured design method for code generation. AC.vt SIGSOFT, Software Engineering :'-!ot~s. I-I( l l. January 1989. J~ -55.

[Wegner87) Wegner, P. Dimensions of ohjcct-h(t-ed language dc~ign. Special Issue of SIGPLA:-J :"otices. ::~1 l~l. October l%i

fWhiting90] Whiting. M.A .. and DeVaney. D. 11-1. Workshop: Finding the object. OOPSL.A/F.COOP .::onrcrcnce proc.:edings. Octoh.:r 1990. pp. 99-107.

[Whi ting93[ Whiung .. \-1. A. Personall·orrcspnndence. 1993.

[Wilson88[ Wilson. D. A. comments maue by D. A. Wilson during panel session. Teaching OOP. OOPSLA conf.:rence pra<:eo:ding,. S.:prember 19 8. pp. 386-387.

[Wirf~81 Wirfs-Brock. A .. and Wilkerson. B. An overview of modular Smalhalk. OOPSLA conft:rence proce.eding>. Seplc!ml:>.!r 19SX. pp. 123-13-1.

[Wirf>89) Wirfs-13rock. R .. and Wilker,on. l3 Ohject-Orit:nted desi~n: A re!>ponsibil ity·driven approach. OOPS Lt\ t:onference proceedings. 1989, pp. 71-7 5.

[Wirfs90a [ Wirf>·Brock R .. Wilkerson. B .. and W.:in.:r. L. Designing object oriented >Oft ware. Englewood Cliff;,. 1-\cw Jer~ey. Prentice-Hall. 1990.

[Wirfs90bl Wirfs·Brock. R .. and John!>on. R. E. Survey1ng current n:~earch in object·oriem.:d de,ign. Commumcauon' ·~f the AC\1. 33C9l. September 1990. \!}4-1 ~--~.

JWirfs90c] Wirfs-Brock. A. Vlissadcs. J .. Cunningham. W., Johnson. R .. and Bollene, L. Panel: o.:~agning reusable de~ign': Experiences designing object oriented fr~meworks. OOPSLNECOOP conference pro..:eeding$. 1990. pp. 19-2~.

1Woodfield87J Woodfield. S .. Embley. D. W .. :Jnd S<.:Otl. D. T. Can programmers reuse software" lEGE Software, July !9R7. 52-59.

(Wybolt901 Wybol t. '\. Experiences with C++ .md object-oriented software development. L:SE:"\IX C·"-'· conferent'l: proce..:ding>. 1990. pp. 1-9.

(Yakemovic90] Yakemovic. K. C. B. The bouom line: t.:sing OOP in a commercial environment. OOPSl..AII:COOP conferenct! prtx:e<!dings. 1990. pp. 93-97.