172 Chapter 10 Mec hanisms for Soft w are Reuse Ob - PDF document

172

Chapter 10 Mec hanisms for Soft w are Reuse Ob ject-orien ted programming has b een billed as the tec hnology that will �nally p ermit soft w are to b e constructed from general-purp ose reusable comp onen ts. W riters suc h as Brad Co x ha v e ev en gone so far as to describ e ob ject orien tation as heralding the \industrial rev olution" in soft w are dev elopmen t [Co x 1986 ]. While the realit y ma y not quite matc h the exp ectations of OOP pioneers, it is true that ob ject-orien ted programming mak es p ossible a lev el of soft w are reuse that is orders of magnitude more p o w erful than that p ermitted b y previous soft w are construction tec hniques. In this c hapter, w e will in v estigate the t w o most common mec hanisms for soft w are reuse, whic h are kno wn as inheritanc e and c omp osition . Inheritance in Ja v a is made more �exible b y the presence of t w o di�eren t mec hanisms, in terfaces and sub classing. In addition to con trasting inheritance and comp osition, w e will con trast inheritance p erformed using sub classing and inheritance p erformed using in terfaces, and relate all to the concept of substitutabilit y . 10.1 Substitutabilit y The concept of substitutabilit y fundamen tal to man y of the most p o w erful soft w are dev el- opmen t tec hniques in ob ject-orien ted programming. Y ou will recall that substitutabilit y referred to the situations that o ccurs when a variable declared as one t yp e is used to hold a value deriv ed from another t yp e. In Ja v a, substitutabilit y can o ccur either through the use of classes and inheritance, or through the use of in terfaces. W e ha v e seen examples of b oth in our earlier case studies. In the Pin Ball game program describ ed in Chapter 7, the v ariable w as declared as a ta rgets rget , but in fact held a v ariet y of di�eren t t yp es of v alues that w ere created using PinBallT a sub classes of rget . In the Solitaire program from Chapter 9, the v ariable PinBallT a allPiles w as declared as holding a rdPile , but in fact held v alues that w ere sub classes of rdPile , Ca Ca suc h as DeckPile and Disca rdPile : 173

174 CHAPTER 10. MECHANISMS F OR SOFTW ARE REUSE f public class Solitare static public CardPile allPiles [ ]; f public void init () ... allPiles = new CardPile[13]; // then �ll them in allPiles[0] = new DeckPile(335, 30); allPiles[1] = new DiscardPile(268, 30); g ... g W e ha v e also seen examples of substitutabilit y arising through in terfaces. An example is the instance of the class FireButtonListener created in the Cannon-ball game (Chapter 6). The class from whic h this v alue w as de�ned w as declared as implemen ting the in terface ActionListener . Because it implemen ts the ActionListener in terface, w e can this v alue as a parameter to a function (in this case, addActionListener ) that exp ects an ActionListener v alue. class CannonWorld extends Frame f ... private class FireButtonListe ner implements ActionListener f public void actionPerformed (ActionEvent e) f ... g g public CannonWorld () f ... fire.addActionL ist en er( ne w FireButtonListe ne r() ); g g W e will return to the distinction b et w een inheritance of classes and inheritance of in ter- faces in Section 10.1.2. 10.1.1 The Is-a Rule and the Has-a Rule A commonly emplo y ed rule-of-th um b that can b e used to understand when inheritance is an appropriate soft w are tec hnique is kno wn collo quially as is-a and has-a (or p art-of )

10.1. SUBSTITUT ABILITY 175 relationship. The is-a relationship holds b et w een t w o concepts when the �rst is a sp ecialized instance of the second. That is, for all practical purp oses the b eha vior and data asso ciated with the more sp eci�c idea form a subset of the b eha vior and data asso ciated with the more abstract idea. F or example, all the examples of inheritance w e describ ed in the early c hapters satisfy the is-a relationship (a Flo rist is-a Shopk eep er , a Dog is-a Mammal , a PinBall is-a Ball , and so on). The relationship deriv es its name from a simple rule of th um b that tests the relationship. T o determine if concept is a sp ecialized instance of concept Y , simply form X the English sen tence \ A Y ". If the assertion \sounds correct," that is, if it seems to n X is a matc h y our ev eryda y exp erience, y ou ma y judge that and ha v e the relationship. X Y is-a The has-a relationship, on the other hand, holds when the second concept is a comp onen t of the �rst but the t w o are not in an y sense the same thing, no matter ho w abstract the generalit y . F or example, a Ca r has-a Engine , although clearly it is not the case that a Ca r is-a Engine or that an Engine is-a Ca r . A Ca r , ho w ev er, is-a V ehicle , whic h in turn is-a MeansOfT ransp o rtation . Once again, the test for the has-a relationship is to simply form the English sen tence \ A n X has a Y ", and let common sense tell y ou whether the result sounds reasonable. Most of the time, the distinction is clear-cut. But, sometimes it ma y b e subtle or ma y dep end on circumstances. In Section 10.2 w e will use one suc h inde�nite case to illustrate the t w o soft w are dev elopmen t tec hniques that are naturally tied to these t w o relationships. 10.1.2 Inheritance of Co de and Inheritance of Beha vior There are at least t w o di�eren t w a ys in whic h a concept can satisfy the is-a relationship with another concept, and these are re�ected in t w o di�eren t mec hanisms in the Ja v a language. Inheritance is the mec hanism of c hoice when t w o concepts share structur e or c o de relationship with eac h other, while an in terface is the more appropriate tec hnique when t w o concepts share the ehavior , but no actual co de. sp e ci�c ation of b This can b e illustrated with examples from the Ja v a run-time library . The class F rame , from whic h most Ja v a windo ws inherit, pro vides a great deal of co de, in the form of metho ds that are inherited and used without b eing o v erridden. Th us, inheritance using the extends mo di�er in the class heading is the appropriate mec hanism to use in this situation. a cannon game is a t yp e of F rame // public class CannonGame extends Frame f ... g On the other hand, the c haracteristics needed for an (the ob ject t yp e that ActionListener resp onds to button presses) can b e describ ed b y a single metho d, and the implemen tation of that metho d cannot b e predicted, since it di�ers from one application to another. Th us,