第14章-原则模式.docVIP

原则和模式 为了有效地使用像UML这样的设计表示法，只是掌握不同类型的语法和语义是不够的。形式表示法的可用性并不能保证会很好地使用这些表示法，好的设计和不好的设计都可以用UML表达。 当然，好的设计和不好的设计之间的不同特征是很难用纯粹的形式词语描述的，很可能在任何完备程度上也不可能做到。推荐某些方法，保证设计师做出的设计一定是好的设计也非常困难。然而现在已经有了面向对象建模和设计的大量经验，使我们可以更好地理解怎样做可能会使设计成功或不成功。 面向对象设计师们积累的经验可以分为两个不同的范畴。一类是一些广泛认可的高级设计原则。这些原则描述了设计应当具有的或者应当避开的值得注意的性质。对于依据这些原则的基本原理所指出的设计特征建立的系统，经验证实，可以预知其结果。 这些高级原则是很重要的，但是对于试图针对具体应用建模的设计师，却几乎不能提供可操作的指导。针对这些情况，需要一些记实性地描述不同种类的设计知识，这些知识更关注特定的问题和解决这些问题的策略。当前在设计模式方面的工作就是通过识别共同的建模问题，并对这些问题提供经过验证的解决方案的方式，满足这种需要。 本章将讨论若干已知的广泛接受的面向对象设计的原则，然后介绍设计模式的概念。模式的用法将通过考虑对本书前面章节中出现的程序的修改予以介绍。 14.1 开-闭原则 开（放）-（封）闭原则是Bertrand Meyer 1988年在他的有影响的著作《面向对象的软件构造》中阐述的。这个原则关注的是系统内部改变的影响，特别是最大限度地使模块免受它所使用的其它模块改变的影响的办法。 考虑系统中一个模块使用另一个模块提供的服务的情况。通常称前一个模块为客户（client），后一个模块为供应者（supplier）。虽然这两个概念有更广泛的使用，本章详细考虑的只是用于类之间的关系，即可以用UML的使用依赖建模的关系。图14.1表示了这种情况。 图14.1 客户类和供应者类之间的使用依赖 如果一个模块不受进一步改变的影响，则称此模块是关闭的。这意味着，客户模块可以放心地使用该模块而无须担心该模块的改变会使客户模块也必须改变。关闭一个模块是有好处的，因为这意味着这个模块以后可以作为系统的一个稳定的构件使用，它不再受到进一步改变的影响，而这种改变将会反过来影响到设计的其他部分。 如果一个模块仍然是可以扩展的，用Meyer的词语，称该模块是开放的。扩展一个模块意味着增加该模块的能力或扩展它的功能。有开放模块是有好处的，因为这样使扩展和修改系统成为可能。由于系统需求很少是稳定不变的，容易扩展模块的能力是降低系统维护费用的一个重要方面。 开-闭原则说明，开发者应当力求使所设计的模块既是开放的同时又是封闭的。如上所述，从既开放又封闭的模块可以得到重要的好处。然而初看起来，开-闭原则似乎有些似是而非，因为很难设想，一个模块怎么可能既是开放的同时又是封闭的。 如果“开放”的定义是指能够改变一个模块，那么一个模块既是开的又是闭的是有矛盾的。然而“开放”的定义只是说一个模块应当是可以扩展的。为了避免矛盾就必须找出一种办法，可以扩展该模块而又不改变该模块。 解决这个问题的一般方案是区分一个模块的接口和它的实现。如果一个模块的这两个方面可以分离，使客户模块仅依赖它的供应者模块的接口，那么供应者模块实现的修改就不会影响客户模块。面向对象程序设计语言提供了许多方法，使一个类的接口可以与它的实现区别开来，本节将对支持开-闭原则需要的相应的机制，做一简要的描述和评价。 14．1．1 数据抽象 使用数据抽象的意图，是通过使实现细节对客户代码不可见的办法，将数据类型或者类与它的实现相分离。这样，可以设想数据抽象能够构造一个既是开放同时又是封闭的模块。在面向对象程序设计语言中，数据抽象是通过指定类的每个特征的访问级，例如“公有的”或“私有的”提供的。图14.2 通过对供应者类的特征定义典型的访问级，表示了一般的客户-供应者关系。 图14.2 使用数据抽象的客户-供应者关系 访问级在UML中也称为可见性，它指明了客户可以看到一个类的哪些特征。图14.2中供应者类中的操作声明为公有的因此客户可以看到，而属性是私有的因而是不可见的。 从客户的视角看，类的接口是仅有的可见的特征。如果可见的接口保持不变，不可见的特征可以改变、去掉或增加，都不会对客户产生影响。例如，在Java中，图14.2中的供应者类可以如下实现。 这个类中公有方法的实现可以改变而不会对客户类有任何影响，类似地，支持该类的方法实现所需要的私有域也可以增加或去掉。为了避免影响客户，必须保持不变的只是由该类公有方法的名称和特征标记（signature）组成的可见接口。 然而实现开-闭原则的这种方式有许多局限。从根本上讲，由于系统的修改要求改变客户类