38
Chapter 3 Ob ject-Orien ted Design A sup er�cial description of the distinction b et w een an ob ject-orien ted language, suc h as Ja v a, and a con v en tional programming language, suc h as P ascal, migh t concen trate on syn- tactic di�erences. In this area discussion w ould cen ter on topics suc h as classes, inheritance, message passing, and metho ds. But suc h an analysis miss the most imp ortan t p oin t of ob ject-orien ted programming, whic h has nothing to do with syn tax. W orking in an ob ject-orien ted language (that is, one that supp orts inheritance, message passing, and classes) is neither a necessary nor su�cien t condition for doing ob ject-orien ted programming. As w e emphasized in Chapter 1, an ob ject-orien ted program is lik e a com- m unit y of in teracting individuals, eac h ha ving assigned resp onsibilities, w orking together to w ards the attainmen t of a common goal. As in real life, a ma jor asp ect in the design of suc h a comm unit y is determining the sp eci�c resp onsibilities for eac h mem b er. T o this end, practicioners of ob ject-orien ted design ha v e dev elop ed a design tec hnique driv en b y the sp eci�cation and delegation of resp onsibilities. This tec hnique has b een called r esp onsibility- [Wirfs-Bro c k 1989b , Wirfs-Bro c k 1990 ]. driven design 3.1 Resp onsibilit y Implies Nonin terference As an y one can attest who can remem b er b eing a c hild, or who has raised c hildren, resp onsi- bilit y is a sw ord that cuts b oth w a ys. When y ou mak e an ob ject (b e it a c hild or a soft w are system) resp onsible for sp eci�c actions, y ou exp ect a certain b eha vior, at least when the rules are observ ed. But just as imp ortan t, resp onsibilit y implies a degree of indep endence or nonin terference. If y ou tell a c hild that she is resp onsible for cleaning her ro om, y ou do not normally stand o v er her and w atc h while that task is b eing p erformed{that is not the nature of resp onsibilit y . Instead, y ou exp ect that, ha ving issued a directiv e in the correct fashion, the desired outcome will b e pro duced. Similarly , in the �o w ers example from Chapter 1, I giv e the request to deliv er �o w ers to 39
40 CHAPTER 3. OBJECT-ORIENTED DESIGN m y �orist without stopping to think ab out ho w m y request will b e serviced. Flora, ha ving tak en on the resp onsibilit y for this service, is free to op erate without in terference on m y part. The di�erence b et w een con v en tional programming and ob ject-orien ted programming is in man y w a ys the di�erence b et w een activ ely sup ervising a c hild while she p erforms a task, and delegating to the c hild resp onsibilit y for that p erformance. Con v en tional programming pro ceeds largely b y doing something to something else{mo difying a record or up dating an arra y , for example. Th us, one p ortion of co de in a soft w are system is often in timately tied, b y con trol and data connections, to man y other sections of the system. Suc h dep endencies can come ab out through the use of global v ariables, through use of p oin ter v alues, or simply through inappropriate use of and dep endence on implemen tation details of other p ortions of co de. A resp onsibilit y-driv en design attempts to cut these links, or at least mak e them as unobtrusiv e as p ossible. This notion migh t at �rst seem no more subtle than the notions of information hiding and mo dularit y , whic h are imp ortan t to programming ev en in con v en tional languages. But resp onsibilit y-driv en design elev ates information hiding from a tec hnique to an art. This principle of information hiding b ecomes vitally imp ortan t when one mo v es from program- ming in the small to programming in the large. One of the ma jor b ene�ts of ob ject-orien ted programming o ccurs when soft w are subsys- tems are reused from one pro ject to the next. F or example, a sim ulation system migh t w ork for b oth a sim ulation of balls on a billiards table and a sim ulation of �sh in a �sh tank. This abilit y to reuse co de implies that the soft w are can ha v e almost no domain-sp eci�c com- p onen ts; it m ust totally delegate resp onsibilit y for domain-sp eci�c b eha vior to application- sp eci�c p ortions of the system. The abilit y to create suc h reusable co de is not one that is easily learned{it requires exp erience, careful examination of case studies (paradigms, in the original sense of the w ord), and use of a programming language in whic h suc h delegation is natural and easy to express. In subsequen t c hapters, w e will presen t sev eral suc h examples. 3.2 Programming in the Small and in the Large The di�erence b et w een the dev elopmen t of individual pro jects and of more sizable soft w are systems is often describ ed as programming in the small v ersus programming in the large. Programming in the small c haracterizes pro jects with the follo wing attributes: Co de is dev elop ed b y a single programmer, or p erhaps b y a v ery small collection of � programmers. A single individual can understand all asp ects of a pro ject, from top to b ottom, b eginning to end. The ma jor problem in the soft w are dev elopmen t pro cess is the design and dev elopmen t � of algorithms for dealing with the problem at hand. Programming in the large, on the other hand, c haracterizes soft w are pro jects with fea- tures suc h as the follo wing:
3.3. WHY BEGIN WITH BEHA VIOR? 41 The soft w are system is dev elop ed b y a large team of programmers. Individuals in v olv ed � in the sp eci�cation or design of the system ma y di�er from those in v olv ed in the co ding of individual comp onen ts, who ma y di�er as w ell from those in v olv ed in the in tegration of v arious comp onen ts in the �nal pro duct. No single individual can b e considered resp onsible for the en tire pro ject, or ev en necessarily understands all asp ects of the pro ject. The ma jor problem in the soft w are dev elopmen t pro cess is the managemen t of details � and the comm unication of information b et w een div erse p ortions of the pro ject. While the b eginning studen t will usually b e acquain ted with programming in the small, asp ects of man y ob ject-orien ted languages are b est understo o d as resp onses to the problems encoun tered while programming in the large. Th us, some appreciation of the di�culties in v olv ed in dev eloping large systems is a helpful prerequisite to understanding OOP . 3.3 Wh y Begin with Beha vior? Wh y b egin the design pro cess with an analysis of b eha vior? The simple answ er is that the b eha vior of a system is usually understo o d long b efore an y other asp ect. Earlier soft w are dev elopmen t tec hniques concen trated on ideas suc h as c haracterizing the basic data structures or the o v erall sequence of function calls, often within the creation of a formal sp eci�cation of the desired application. But structural elemen ts of the appli- cation can b e iden ti�ed only after a considerable amoun t of problem analysis. Similarly , a formal sp eci�cation often ended up as a do cumen t understo o d b y neither programmer nor clien t. But is something that can b e describ ed almost from the momen t an idea b ehavior is conceiv ed, and (often unlik e a formal sp eci�cation) can b e describ ed in terms meaningful to b oth the programmers and the clien t. W e will illustrate the application of Resp onsibilit y-Driv en Design (RDD) with a case study . 3.4 A Case Study in RDD Imagine y ou are the c hief soft w are arc hitect in a ma jor computer �rm. One da y y our b oss w alks in to y our o�ce with an idea that, it is hop ed, will b e the next ma jor success in y our pro duct line. Y our assignmen t is to dev elop the Inter active Intel ligent Kitchen Help er (Figure 3.1). The task giv en to y our soft w are team is stated in v ery few w ords, written on what app ears to b e the bac k of a sligh tly-used dinner napkin, in handwriting that app ears to b e y our b oss's.
Recommend
More recommend
