P art I Understanding the Ob ject-Orien ted W orld View 11 - PDF document

P art I Understanding the Ob ject-Orien ted W orld View 11

Chapter 1 Ob ject-Orien ted Thinking This is a b o ok ab out ob ject-orien ted programming. In particular, this is a b o ok that explores the principle ideas of ob ject-orien ted programming in the con text of the Ja v a programming language. Ob ject-orien ted programming has b een a hot topic for o v er a decade, and more recen tly Ja v a has b ecome the commonly p erceiv ed em b o dimen t of ob ject-orien ted ideas. This b o ok will help y ou Ja v a. It mak es no pretensions to b eing a language understand reference man ual; there are man y other b o oks that fall in to that category . But kno wing the syn tax for a language should not b e confused with an understanding of wh y the language has b een dev elop ed in the w a y it has, wh y certain things are done the w a y they are, or wh y Ja v a programs lo ok the w a y they do. This b o ok explores this issue of why . Ob ject-orien ted programming is frequen tly referred to as a new programming p ar adigm . The w ord paradigm originally mean t example, or mo del. F or example, a paradigm sen tence w ould help y ou remem b er ho w to conjugate a v erb in a foreign language. More generally , a mo del is an example that helps y ou understand ho w the w orld w orks. F or example, the Newtonian mo del of ph ysics explains wh y apples fall to the ground. In computer science, a paradigm explains ho w the elemen ts that go in to making a computer program are organized and ho w they in teract with eac h other. F or this reason the �rst step in understanding Ja v a is appreciating the ob ject-orien ted w orld view. 1.1 A W a y of Viewing the W orld T o illustrate the ma jor ideas in ob ject-orien ted programming, let us consider ho w w e migh t go ab out handling a real-w orld situation and then ask ho w w e could mak e the computer more closely mo del the tec hniques emplo y ed. Supp ose I wish to send �o w ers to a friend who liv es in a cit y man y miles a w a y . Let me call m y friend Sally . Because of the distance, there is no p ossibilit y of m y pic king the �o w ers and carrying them to her do or m yself. Nev ertheless, sending her the �o w ers is an easy enough task; I merely go do wn to m y lo cal �orist (who 13

14 CHAPTER 1. OBJECT-ORIENTED THINKING Sally Delivery P erson Ga rdeners E C E C E Gro w er Flo w er Arranger E � ME Flo ra E � � @ E � Wholesaler @ Sally's Flo rist Figure 1.1: The comm unit y of agen ts helping me happ ens to b e named Flora), tell her the v ariet y and quan tit y of �o w ers I wish to send and giv e her Sally's address, and I can b e assured the �o w ers will b e deliv ered exp edien tly and automatically . 1.1.1 Agen ts and Comm unities A t the risk of b elab oring a p oin t, let me emphasize that the mec hanism I used to solv e m y problem w as to �nd an appropriate agent (namely , Flora) and to pass to her a message con taining m y request. It is the r esp onsibility of Flora to satisfy m y request. There is some metho d {some algorithm or set of op erations{used b y Flora to do this. I do not need to kno w the particular metho d she will use to satisfy m y request; indeed, often I do not w an t to kno w the details. This information is usually hidden from m y insp ection. If I in v estigated ho w ev er, I migh t disco v er that Flora deliv ers a sligh tly di�eren t message to another �orist in m y friend's cit y . That �orist, in turn, p erhaps has a sub ordinate who mak es the �o w er arrangemen t. The �orist then passes the �o w ers, along with y et another message, to a deliv ery p erson, and so on. Earlier, the �orist in Sally's cit y had obtained her �o w ers from a �o w er wholesaler who, in turn, had in teractions with the �o w er gro w ers, eac h of whom had to manage a team of gardeners. So, our �rst observ ation of ob ject-orien ted problem solving is that the solution to m y problem required the help of man y other individuals (Figure 1.1). Without their help, m y problem could not b e easily solv ed. W e phrase this in a general fashion as the follo wing: An ob ject orien ted program is structured as a of in teracting agen ts, c ommunity called cts . Eac h ob ject has a role to pla y . Eac h ob ject pro vides a service, or obje p erforms an action, that is used b y other mem b ers of the comm unit y .

1.1. A W A Y OF VIEWING THE W ORLD 15 1.1.2 Messages and Metho ds The c hain reaction that ultimately resulted in the solution to m y program b egan with m y request to Flora. This request lead to other requests, whic h lead to still more requests, un til m y �o w ers ultimately reac hed m y friend. W e see, therefore, that mem b ers of this comm unit y in teract with eac h other b y making requests. So, our next principle of ob ject- orien ted problem solving is the v ehicle b y whic h activities are initiated: Action is initiated in ob ject-orien ted programming b y the transmission of a mes- sage to an agen t (an obje ct ) resp onsible for the action. The message enco des the request for an action and is accompanied b y an y additional information (argu- men ts) needed to carry out the request. The r e c eiver is the ob ject to whom the message is sen t. If the receiv er accepts the message, it accepts the resp onsibilit y to carry out the indicated action. In resp onse to a message, the receiv er will p erform some metho d to satisfy the request. W e ha v e noted the imp ortan t principle of in regard to message information hiding passing{that is, the clien t sending the request need not kno w the actual means b y whic h the request will b e honored. There is another principle, all to o h uman, that w e see is implicit in message passing. If there is a task to p erform, the �rst though t of the clien t is to �nd some- b o dy else he or she can ask to do the w ork. This second reaction often b ecomes atrophied in man y programmers with extensiv e exp erience in con v en tional tec hniques. F requen tly , a di�cult h urdle to o v ercome is the idea in the programmer's mind that he or she m ust write ev erything and not use the services of others. An imp ortan t part of ob ject-orien ted programming is the dev elopmen t of reusable comp onen ts, and an imp ortan t �rst step in the use of reusable comp onen ts is a willingness to trust soft w are written b y others. Information hiding is also an imp ortan t asp ect of programming in con v en tional lan- guages. In what sense is a message di�eren t from, sa y , a pro cedure call? In b oth cases, there is a set of w ell-de�ned steps that will b e initiated follo wing the request. But, there are t w o imp ortan t distinctions. The �rst is that in a message there is a designated r e c eiver for that message; the receiv er is some ob ject to whic h the message is sen t. In a pro cedure call, there is no designated receiv er. The second is that the interpr etation of the message (that is, the metho d used to resp ond to the message) is dep enden t on the receiv er and can v ary with di�eren t receiv ers. I can giv e a message to m y wife Elizab eth, for example, and she will understand it and a satisfactory outcome will b e pro duced (that is, �o w ers will b e deliv ered to m y friend). Ho w ev er, the metho d Elizab eth uses to satisfy the request (in all lik eliho o d, simply passing the request on to Flora) will b e di�eren t from that used b y Flora in resp onse to the same request. If I ask Kenneth, m y den tist, to send �o w ers to m y friend, he ma y not ha v e a metho d for solving that problem. If he understands the request at all, he will probably issue an appropriate error diagnostic.