软件设计模式 黄洪 hhzjut@gmail.com

课程目的 学习面向对象设计中前人最有价值的经验总结---设计模式。以便重用优秀、简单的、经过验证的问题解决方案。 设计模式实际上讨论的是在解决面向对象设计的某类问题时，应该设计那些类，这些类之间应该如何通信。 设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统的开发者更加容易理解其设计思路。设计模式帮助你做出有利于系统复用的选择，避免设计损害了系统复用性。通过提供一个类和对象作用关系以及它们之间潜在联系的说明规范，设计模式甚至能够提高已有系统的文档管理和系统维护的有效性。简而言之，设计模式可以帮助设计者更快更好地完成系统设计。 学习设计模式的重要性

参考书目 （美） GoF, 设计模式-可复用的面向对象软件的基础，机械工业出版社，2005 （美）Elisabeth Freeman,Eric Freeman,Bert Bates,Kathy Sierra ，《深入浅出设计模式》（英文影印版），东南大学出版社，2005 （美）Alan Holub，《设计模式初学者指南》，机械工业出版社，2006 洁城 浩，《设计模式-JAVA语言中的应用》，中国铁道出版社2005.1 http://www.jdon.com/designpatterns/index.htm（板桥里人）

第一讲 设计模式简介 主要内容 设计模式的起源 什么是设计模式 设计模式的描述 设计模是怎样解决设计问题

设计模式起源于建筑学 著名建筑师Christopher Alexander 写过一本关于建筑学的书，叫做A Pattern Language，中译本叫做《建筑模式语言》，书中将解决一些共同建筑设计问题的优秀方案的相似之处称作“模式”。 他对模式的定义是“在某一背景下某个问题的一种解决方案”，“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的要素。这样，该解决方案就能被反复地使用而不必做重复劳动，但具体方式可能不会完全相同” 这就是建筑模式

模式的四个要素 模式名称（pattern name） 模式的目的/问题(problem) 实现方法/解决方案(solution) 一个助记名，它用一两个词来描述模式的问题、解决方案和效果。 模式的目的/问题(problem) 描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题。 实现方法/解决方案(solution) 描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种不同场合，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一般意义的元素组合来解决这个问题。 效果(consequences) 描述了模式应用的效果及使用模式应权衡的问题（限制和约束因素）。

从建筑模式到软件设计模式 软件开发人员认识到，Alexander 关于“建筑模式” 的思想也同样适用于软件设计，因为软件中也存在不断重复出现的、可以以某种相同方式解决的问题。尤其是面向对象的软件设计，只是在面向对象的解决方案里，我们用对象和接口代替了墙壁和门窗。两类模式的核心都在于提供了相关问题的解决方案。 20世纪90年代，软件设计模式的代表性研究成果《设计模式：可复用面向对象软件的基础》一书诞生，其作者是被称作四人帮（GoF）的四位学者。

请编程解决以下问题 一个交通查询系统，输入交通工具类型（如汽车、飞机）和起始地点，系统给出到目的地所需的时间。 为了简化问题，起始地点改成里程。 每种交通工具应该是一个类（对象），具有一个计算平均速度的方法，该方法根据三个参数a,b,c来计算平均速度。 如：汽车的平均速度 = a*b/c 飞机的平均速度=a+b+c等等 提示：交通工具名等参数可以通过main方法的参数传递；用Class.forName(交通工具名).newInstance()可以生成交通工具的对象。

问题 如果出现新的交通工具，你设计的系统能否不修改原来的代码就进行扩充，实现对新的交通工具运行时间的查询？

一个好的解决方案 采用面向接口的编程原则的一个解决方案。 对于一种经常遇到的设计问题的经过验证的优秀解决方案进行提炼，即可得到一种设计模式。今后遇到类似设计问题时，就可以采用这一解决方案。

设计模式的定义 一个设计模式命名、抽象和确定了一个优秀的通用设计结构的主要方面，这些设计结构能被用来构造可复用的面向对象设计。设计模式确定了所包含的类和对象，它们的角色、协作方式以及职责分配。每一个设计模式都集中于一个特定的面向对象设计问题或设计要点，描述了什么时候使用它，在另一些设计约束条件下是否还能使用，以及使用的效果和如何取舍。 设计模式可以看作是面向对象设计领域的“定式”。

GoF(Gang of Four) Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides 被称为四人组 1995合著 Design Patterns Elements of Reusable Object-Oriented Software，这是设计模式的一本经典之作。

为什么应该学习设计模式 方便地复用成功的设计方案，提高设计质量。 确立通用的术语，改善团队沟通。 提审思考的层次 判断设计是否正确 改善个人和团队的学习 提高代码的可修改性和可维护性 通过掌握一些优秀的面向对象设计策略，使得设计者即使没有明确使用模式，也能采用更好的设计方案 帮助发现巨型继承结构的替代方案

对设计模式的描述 用统一的格式描述设计模式，对一个模式的描述包括以下部分： 模式名和分类 意图：描述模式的目的 问题/动机：模式要解决的问题 解决方案：模式怎样为问题提供适合其所处环境的一个解决方案 参与者和协作者：模式所涉及的实体 效果：使用模式的效果，研究模式中起作用的各种因素 实现：模式的实现方式 一般结构：描述模式典型结构的标准图（采用基于对象建模技术对模式中的类进行图形描述）

设计模式的编目 Abstract Factory( 3 . 1 )：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 A d a p t er ( 4 . 1 )：将一个类的接口转换成客户希望的另外一个接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 B r i d g e( 4 . 2 )：将抽象部分与它的实现部分分离，使它们都可以独立地变化。 B u i l d e r( 3 . 2 )：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。 Chain of Responsibility( 5 . 1 )：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。

设计模式的编目 C o m m a n d( 5 . 2 )：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。 C o m p o s i t e( 4 . 3 )：将对象组合成树形结构以表示“部分-整体”的层次结构。C o m p o s i t e使得客户对单个对象和复合对象的使用具有一致性。 D e c o r a t o r( 4 . 4 )：动态地给一个对象添加一些额外的职责。就扩展功能而言， D e c o r a t o r模式比生成子类方式更为灵活。 F a c a d e( 4 . 5 )：为子系统中的一组接口提供一个一致的界面， F a c a d e模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

设计模式的编目 Factory Method( 3 . 3 )：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。Factory Method使一个类的实例化延迟到其子类。 F l y w e i g h t( 4 . 6 )：运用共享技术有效地支持大量细粒度的对象。 I n t e r p r e t e r( 5 . 3 )：给定一个语言, 定义它的文法的一种表示，并定义一个解释器, 该解释器使用该表示来解释语言中的句子。 I t e r a t o r( 5 . 4 )：提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。

设计模式的编目 M e d i a t o r( 5 . 5 )：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。 M e m e n t o( 5 . 6 )：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。 O b s e r v e r( 5 . 7 )：定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新。 P r o t o t y p e( 3 . 4 )：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。

设计模式的编目 P r o x y( 4 . 7 )：为其他对象提供一个代理以控制对这个对象的访问。 S i n g l e t o n( 3 . 5 )：保证一个类仅有一个实例，并提供一个访问它的全局访问点。 S t a t e( 5 . 8 )：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。 S t r a t e g y (5 . 9 )：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。 Template Method( 5 . 1 0 )：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 Vi s i t o r( 5 . 11 )：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

设计模式分类 根据模式目的来分。即模式是用来完成什么工作的。模式依据其目的可分为创建型（ C r e a t i o n a l ）、结构型( S t r u c t u r a l )、或行为型( B e h a v i o r a l )三种。 创建型模式与对象的创建有关； 结构型模式处理类或对象的组合； 行为型模式对类或对象怎样交互和怎样分配职责进行描述。 根据模式的范围分，指定模式主要是用于类还是用于对象。 类模式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了。 对象模式处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性。

模式分类表 目的 创建型 结构型 行为型 范围 类 对象 Abstract Factory(3.1) Factory Method(3.3) A d a p t e r (类) ( 4 . 1 ) I n t e r p r e t e r ( 5 . 3 ) Template Method(5.10) 对象 Abstract Factory(3.1) B u i l d e r ( 3 . 2 ) P r o t o t y p e ( 3 . 4 ) S i n g l e t o n ( 3 . 5 ) A d a p t e r (对象) ( 4 . 1 ) B r i d g e ( 4 . 2 ) C o m p o s i t e ( 4 . 3 ) D e c o r a t o r ( 4 . 4 ) F a c a d e ( 4 . 5 ) F l y w e i g h t ( 4 . 6 ) P r o x y ( 4 . 7 ) Chain of Responsibility(5.1) C o m m a n d ( 5 . 2 ) I t e r a t o r ( 5 . 4 ) M e d i a t o r ( 5 . 5 ) M e m e n t o ( 5 . 6 ) O b s e r v e r ( 5 . 7 ) S t a t e ( 5 . 8 ) S t r a t e g y ( 5 . 9 ) Vi s i t o r ( 5 . 1 0 )

模式之间的关系 还有一种方式是根据模式的“相关模式”部分所描述的它们怎样互相引用来组织设计模式。 图1 - 1给出了模式关系的图形说明。

设计模式怎样解决设计问题 设计模式采用多种方法解决面向对象设计者经常碰到的问题。这里给出几个问题以及使用设计模式解决它们的方法。 寻找合适的对象 决定对象的粒度 指定对象接口 描述对象的实现 运用复用机制 关联运行时刻和编译时刻的结构 设计应支持变化

设计模式帮助寻找合适的对象 面向对象设计最困难的部分是将系统分解成对象集合。因为要考虑许多因素：封装、粒度、依赖关系、灵活性、性能、演化、复用等等，它们都影响着系统的分解，并且这些因素通常还是互相冲突的。 设计的许多对象来源于现实世界的分析模型。但是，设计结果所得到的类通常在现实世界中并不存在。严格反映当前现实世界的模型并不能产生也能反映将来世界的系统。设计中的抽象对于产生灵活的设计是至关重要的。 设计模式可以帮助确定并不明显的抽象和描述这些抽象的对象。例如，描述过程或算法的对象现实中并不存在，但它们却是设计的关键部分。S t r a t e g y 模式描述了怎样实现可互换的算法族。S t a t e 模式将实体的每一个状态描述为一个对象。这些对象在分析阶段，甚至在设计阶段的早期都并不存在，后来为使设计更灵活、复用性更好才将它们发掘出来。

设计模式帮助决定对象的粒度 对象在大小和数目上变化极大。它们能表示下自硬件或上自整个应用的任何事物。那么我们怎样决定一个对象应该是什么呢？ 设计模式很好地讲述了这个问题。F a c a d e 模式描述了怎样用对象表示完整的子系统，F l y w e i g h t 模式描述了如何支持大量的最小粒度的对象。其他一些设计模式描述了将一个对象分解成许多小对象的特定方法。Abstract Factory和B u i l d e r 产生那些专门负责生成其他对象的对象。Vi s i t o r 和C o m m a n d 生成的对象专门负责实现对其他对象或对象组的请求。

对象接口 一个操作对应的操作名、作为参数的对象和返回值，这就是所谓的操作的型构( s i g n a t u r e )。一个对象所定义的所有操作型构的集合被称为该对象的接口( i n t e r f a c e )。在面向对象系统中，接口是基本的组成部分。对象只有通过它们的接口才能与外部交流，如果不通过对象的接口就无法知道对象的任何事情，也无法请求对象做任何事情。。对象接口与其功能实现是分离的，不同对象可以对请求做不同的实现，也就是说，两个有相同接口的对象可以有完全不同的实现。

对象接口（动态绑定） 当给对象发送请求时，所引起的具体操作既与请求本身有关又与接受对象有关。支持相同请求的不同对象可能对请求激发的操作有不同的实现。发送给对象的请求和它的相应操作在运行时刻的连接就称之为动态绑定(dynamic binding)。

对象接口（多态） 动态绑定是指发送的请求直到运行时刻才受你的具体的实现的约束。因而，在知道任何有正确接口的对象都将接受此请求时，你可以写一个一般的程序，它期待着那些具有该特定接口的对象。进一步讲，动态绑定允许你在运行时刻彼此替换有相同接口的对象。这种可替换性就称为多态( p o l y m o r p h i s m )，它是面向对象系统中的核心概念之一。多态允许客户对象仅要求其他对象支持特定接口，除此之外对其假设几近于无。多态简化了客户的定义，使得对象间彼此独立，并可以在运行时刻动态改变它们相互的关系。

设计模式帮助指定对象接口 设计模式通过确定接口的主要组成成分及经接口发送的数据类型，来帮助你定义接口。 设计模式也许还会告诉你接口中不应包括哪些东西。M e m e n t o ( 5 . 6 )模式是一个很好的例子，它描述了怎样封装和保存对象内部的状态，以便一段时间后对象能恢复到这一状态。它规定了M e m e n t o对象必须定义两个接口：一个允许客户保持和复制m e m e n t o的限制接口，和一个只有原对象才能使用的用来储存和提取m e m e n t o中状态的特权接口。 设计模式也指定了接口之间的关系。特别地，它们经常要求一些类具有相似的接口；或它们对一些类的接口做了限制。例如， D e c o r a t o r ( 4 . 4 )和P r o x y ( 4 . 7 )模式要求D e c o r a t o r和P r o x y对象的接口与被修饰的对象和受委托的对象一致。而Vi s i t o r ( 5 . 11 )模式中，Vi s i t o r接口必须反映出v i s i t o r能访问的对象的所有类。

抽象类 抽象类(abstract class)的主要目的是为它的子类定义公共接口。一个抽象类将把它的部分或全部操作的实现延迟到子类中，因此，一个抽象类不能被实例化。在抽象类中定义却没有实现的操作被称为抽象操作(abstract operation)。非抽象类称为具体类(concrete class)。 子类能够改进和重新定义它们父类的操作。更具体地说，类能够重定义( o v e r r i d e )父类定义的操作，重定义使得子类能接管父类对请求的处理操作。类继承允许你只需简单的扩展其他类就可以定义新类，从而可以很容易地定义具有相近功能的对象族。

类继承与接口继承的比较 理解对象的类( c l a s s )与对象的类型( t y p e ---Java中的接口Interface)之间的差别非常重要。 一个对象的类定义了对象是怎样实现的，同时也定义了对象的内部状态和操作的实现。但是对象的类型只与它的接口有关，接口即对象能响应的请求的集合。一个对象可以有多个类型，不同类的对象可以有相同的类型。 当然，对象的类和类型是有紧密关系的。因为类定义了对象所能执行的操作，也定义了对象的类型。当我们说一个对象是一个类的实例时，即指该对象支持类所定义的接口。

设计模式倡导针对接口编程 面向对象设计的第一个原则：针对接口编程，而不是针对实现编程。 前面的例子已经证明了这个原则。针对接口编程使得系统能具有更好的扩展性和可维护性。

两种复用机制 若已存在一个类ClassA，现在希望复用ClassA，则有以下两种方法。 通过继承实现复用 通过组合实现复用 建立一个新的类，在该类中声明一个ClassA类型的成员变量，让它引用一个ClassA的实例对象，这样就可以通过该引用变量实现对ClassA中方法的复用。

通过组合实现复用的示例代码 class ClassA { … public void methodA( ) {…} //希望被复用的方法 } class NewClass{ ClassA c; //组合 public NewClass( ClassA c1) { c=c1} //让c引用一个ClassA对象 c.methodA( ); //通过c实现对ClassA的复用

运用复用机制 对象组合是类继承之外的另一种复用选择。新的更复杂的功能可以通过组装或组合对象来获得。对象组合要求被组合的对象具有良好定义的接口。这种复用风格被称为黑箱复用(black-box reuse)，因为对象的内部细节是不可见的。

继承机制的优缺点 优点： 缺点 一个可用的解决方法就是只继承抽象类，因为抽象类通常提供较少的实现。 类继承是在编译时刻静态定义的，且可直接使用，因为程序设计语言直接支持类继承。类继承可以较方便地改变被复用的实现。当一个子类重定义一些而不是全部操作时，它也能影响它所继承的操作，只要在这些操作中调用了被重定义的操作。 缺点 因为继承在编译时刻就定义了，所以无法在运行时改变从父类继承的实现。 继承常被认为“破坏了封装性” 。子类中的实现与它的父类有如此紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。 如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。 一个可用的解决方法就是只继承抽象类，因为抽象类通常提供较少的实现。

对象组合的优点 对象组合是通过获得对其他对象的引用而在运行时刻动态定义的。组合要求对象遵守彼此的接口约定，进而要求更仔细地定义接口，而这些接口并不妨碍你将一个对象和其他对象一起使用。这还会产生良好的结果：因为对象只能通过接口访问，所以我们并不破坏封装性；只要类型一致，运行时刻还可以用一个对象来替代另一个对象；更进一步，因为对象的实现是基于接口写的，所以实现上存在较少的依赖关系。 对象组合对系统设计还有另一个作用，即优先使用对象组合有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。另一方面，基于对象组合的设计会有更多的对象(而有较少的类)，且系统的行为将依赖于对象间的关系而不是被定义在某个类中。

设计模式倡导对象组合的复用方式 面向对象设计的第二个原则：优先使用对象组合，而不是类继承。 理想情况下，你不应为获得复用而去创建新的构件。你应该能够只使用对象组合技术，通过组装已有的构件就能获得你需要的功能。但是事实很少如此，因为可用构件的集合实际上并不足够丰富。使用继承的复用使得创建新的构件要比组装旧的构件来得容易。这样，继承和对象组合常一起使用。 经验表明：设计者往往过度使用了继承这种复用技术。但依赖于对象组合技术的设计却有更好的复用性(或更简单)。设计模式中一再使用对象组合技术。