继承的利弊和使用原则.docx

6.7 继承的利弊和?使用原则 继承是一种提?高程序代码的?可重用性，以及提高系统?的可扩展性的?有效手段。在第1章的1?.3.7节（继承、扩展、覆盖）曾经以Ser?vlet为例?，演示了继承在?创建框架类软?件中的运用。但是，如果继承树非?常复杂，或者随便扩展?本来不是专门?为继承而设计?的类，反而会削弱系?统的可扩展性?和可维护性。 6.7.1 继承树的层次?不可太多 继承树（不考虑顶层的?Object?类）的层次应该尽?量保持在两到?三层。图6-5和图6-6分别显示了?设计合理的继?承树和设计不?合理的继承树?。如果继承树的?层次很多，会导致以下弊?端： （1）对象模型的结?构太复杂，难以理解，增加了设计和?开发的难度。继承树底层的?子类会继承上?层所有直接父?类或间接父类?的方法和属性?，假如子类和父?类之间还有频?繁的方法覆盖?和属性被屏蔽?的现象，那么会增加运?用多态机制的?难度，难以预计在运?行时方法和属?性到底和哪个?类绑定。 （2）影响系统的可?扩展性。继承树的层次?越多，在继承树上增?加一个新的继?承分支需要创?建的类越多。 图6-5 设计合理的三?层继承树 图6-6 设计不合理的?六层继承树 6.7.2 继承树的上层?为抽象层 当一个系统使?用一棵继承树?上的类时，应该尽可能地?把引用变量声?明为继承树的?上层类型，这可以提高两?个系统之间的?松耦合。例如动物饲养?员Feede?r的feed?()方法，它的参数为A?nimal和?Food类型?： feed(Animal? animal?,Food food)Tips如果继承树上?有接口类型，那么应该尽可?能地把引用变?量声明为继承?树上层的接口?类型，参见第8章（接口）。 位于继承树上?层的类具有以?下作用： 定义了下层子?类都拥有的相?同属性和方法?，并且尽可能地?为多数方法提?供默认的实现?，从而提高程序?代码的可重用?性。 代表系统的接?口，描述系统所能?提供的服务。 在设计继承树?时，首先进行自下?而上的抽象，即识别子类之?间所拥有的共?同属性和功能?，然后抽象出共?同的父类，位于继承树最?上层的父类描?述系统对外提?供哪些服务。如果某种服务?的实现方式适?用于所有子类?或者大多数子?类，那么在父类中?就实现这种服?务。如果某种服务?的实现方式取?决于各个子类?的特定属性和?实现细节，那么在父类中?无法实现这种?服务，只能把代表这?种服务的方法?定义为抽象方?法，并且把父类定?义为抽象类。 比如热水器父?类可分为电热?水器和燃气热?水器这两个子?类，电热水器和燃?气热水器采用?不同的方式烧?水，在热水器父类?中无法提供烧?水的具体实现?，因此必须把热?水器父类定义?为抽象类。 public? abstra?ct class WaterH?eating?{ /** 烧水 */ public? abstra?ct void heatin?g(); /** 调节水温 */ public? abstra?ct void adjust?(int level); } 由于继承树上?层的父类描述?系统对外提供?的服务，但不一定实现?这种服务，因此把继承树?的上层称为抽?象层。在进行对象模?型设计时，应该充分地预?计系统现在必?须具备的功能?，以及将来需要?新增的功能，然后在抽象层?中声明它们。抽象层应该比?较稳定，这可以提高与?其他系统的松?耦合及系统本?身的可维护性?。 6.7.3 继承关系最大?的弱点：打破封装 继承关系最大?的弱点就是打?破了封装。在第1章的1?.3.5节（封装、透明）介绍封装时，曾经提到每个?类都应该封装?它的属性及实?现细节，这样，当这个类的实?现细节发生变?化时，不会对其他依?赖它的类造成?影响。而在继承关系?中，子类能够访问?父类的属性和?方法，也就是说，子类会访问父?类的实现细节?，子类与父类之?间是紧密耦合?关系，当父类的实现?发生变化时，子类的实现也?不得不随之变?化，这削弱了子类?的独立性。 由于继承关系?会打破封装，这增加了维护?软件的工作量?。尤其在一个J?ava软件系?统使用了一个?第三方提供的?Java类库?的场合。例如在基于W?eb的Jav?a应用中，目前都流行使?用Apach?e开源软件组?织提供的St?ruts框架?，这个框架的一?个扩展点为A?ction类?。在Strut?s 1.0版本中，Action?类有两个方法?：perfor?m()和saveE?rrors()。 public? Action?Forwar?d perfor?m( Action?Mappin?g mappin?g, Action?Form form, Servle?tReque?st reques?t, Servle