202 CHAPTER12. OBJECT-ORIENTEDDESIGN
importantcandidatesforobjects.Thingsthatseemtoinvolve a groupingofrelateddataitems(e.g.,
coordinatesofa pointorpersonaldataaboutanemployee)probablyare.- Identifyinstancevariables.Onceyouhave uncoveredsomepossibleobjects,thinkabouttheinforma-
tionthateachobjectwillneedtodoitsjob. Whatkindsofvalueswilltheinstancevariableshave?
Someobjectattributeswillhave primitive values;othersmightthemselvesbecomplex typesthatsug-
gestotherusefulobjects/classes.Strive tofindgood“home”classesforallthedatainyourprogram. - Thinkaboutinterfaces.Whenyouhave identifieda potentialobject/classandsomeassociateddata,
thinkaboutwhatoperationswouldberequiredforobjectsofthatclasstobeuseful.Youmightstart
byconsideringtheverbsintheproblemstatement.Verbsareusedtodescribeactions—whatmustbe
done.Listthemethodsthattheclasswillrequire.Rememberthatallmanipulationoftheobject’s data
shouldbedonethroughthemethodsyouprovide. - Refinethenontrivialmethods.Somemethodswilllooklike they canbeaccomplishedwitha couple
linesofcode.Othermethodswillrequireconsiderableworktodevelopanalgorithm.Usetop-down
designandstepwiserefinementtofleshoutthedetailsofthemoredifficultmethods.Asyougoalong,
youmayverywelldiscoverthatsomenewinteractionswithotherclassesareneeded,andthismight
forceyoutoaddnew methodstootherclasses.Sometimesyoumaydiscovera needfora brand-new
kindofobjectthatcallsforthedefinitionofanotherclass. - Designiteratively. Asyouworkthroughthedesign,youwillbouncebackandforthbetweendesigning
newclassesandaddingmethodstoexistingclasses.Workonwhateverseemstobedemandingyour
attention. Noonedesignsa programtoptobottomina linear, systematicfashion. Make progress
wherever it seemsprogressneedstobemade. - Tryoutalternatives.Don’t beafraidtoscrapanapproachthatdoesn’t seemtobeworkingortofollow
anideaandseewhereit leads. Gooddesigninvolvesa lotoftrialanderror. Whenyoulookatthe
programsofothers,youareseeingfinishedwork,nottheprocessthey wentthroughtogetthere.If a
programis welldesigned,it probablyis nottheresultofa firsttry. FredBrooks, a legendarysoftware
engineer, coinedthemaxim:“Plantothrowoneaway.” Oftenyouwon’t reallyknowhowa system
shouldbebuiltuntilyou’ve alreadybuiltit thewrongway. - Keepit simple.Ateachstepinthedesign,trytofindthesimplestapproachthatwillsolve theproblem
at hand.Don’t designinextracomplexityuntilit is clearthata morecomplex approachis needed.
Thenextsectionswillwalkyouthrougha couplecasestudiesthatillustrateaspectsofOOD.Onceyou
thoroughlyunderstandtheseexamples,youwillbereadyto tackleyourownprogramsandrefineyourdesign
skills.
12.2 CaseStudy:RacquetballSimulation
Forourfirstcasestudy, let’s returntotheracquetballsimulationfromChapter9.Youmightwanttogoback
andreview theprogramthatwedevelopedthefirsttimearoundusingtop-downdesign.
Thecruxoftheproblemis tosimulatemultiplegamesofracquetballwheretheabilityofthetwo op-
ponentsisrepresentedbytheprobabilitythatthey wina pointwhenthey areserving. Theinputstothe
simulationaretheprobabilityforplayerA,theprobabilityforplayerB,andthenumberofgamestosimu-
late.Theoutputis a nicelyformattedsummaryoftheresults.
Intheoriginalversionoftheprogram,weendeda gamewhenoneoftheplayersreacheda totalof 15
points. Thistimearound,let’s alsoconsidershutouts. Ifoneplayergetsto7 beforetheotherplayerhas
scoreda point,thegameends.Oursimulationshouldkeeptrackofboththenumberofwinsforeachplayer
andthenumberofwinsthatareshutouts.