Upload
buinhu
View
219
Download
0
Embed Size (px)
Citation preview
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 [email protected]
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 objectonemed 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-nle: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 objectoriented 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 toriented 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 objectoriented 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.