ch06第6章软件设计模式基础

1、2 设计模式（设计模式（Design pattern）是一套被反复使用、多数人）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。码可靠性。 设计模式使人们可以更加简单方便地复用成功的设计和体设计模式使人们可以更加简单方便地复用成功的设计和体系结构。将已证实的技术表述成设计模式也会使新系统开发系结构。将已证实的技术表述成设计模式也会使新系统开发者更加容易理解其设计思路。设计模式帮助你做出有利于系者更加容易

2、理解其设计思路。设计模式帮助你做出有利于系统复用的选择，避免设计损害了系统复用性。通过提供一个统复用的选择，避免设计损害了系统复用性。通过提供一个显式类和对象作用关系以及它们之间潜在联系的说明规范，显式类和对象作用关系以及它们之间潜在联系的说明规范，设计模式甚至能够提高已有系统的文档管理和系统维护的有设计模式甚至能够提高已有系统的文档管理和系统维护的有效性。简而言之，设计模式可以帮助设计者更快更好地完成效性。简而言之，设计模式可以帮助设计者更快更好地完成系统设计。系统设计。3 模式是一种特别巧妙和敏锐的用以解决某类特定模式是一种特别巧妙和敏锐的用以解决某类特定问题的最通用和灵活的解决办法。问题

3、的最通用和灵活的解决办法。 模式体现的是程序整体的构思，所以有时候它也模式体现的是程序整体的构思，所以有时候它也会出现在分析或者是概要设计阶段会出现在分析或者是概要设计阶段 增加一个抽象层，把变化的东西从那些不变的东增加一个抽象层，把变化的东西从那些不变的东西里分离出来。西里分离出来。 4 模式名称模式名称(pattern name) ：一个助记名，它用一两一个助记名，它用一两个词来描述模式的问题、解决方案和效果。个词来描述模式的问题、解决方案和效果。 问题问题(problem)：描述了应该在何时使用模式。它解描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了释了设计

4、问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎样用对象表示算法等。也可能特定的设计问题，如怎样用对象表示算法等。也可能描述了导致不灵活设计的类或对象结构。描述了导致不灵活设计的类或对象结构。 解决方案解决方案(solution) ：描述了设计的组成成分，它们描述了设计的组成成分，它们之间的相互关系及各自的职责和协作方式。之间的相互关系及各自的职责和协作方式。 效果效果(consequences) ：描述了模式应用的效果及使描述了模式应用的效果及使用模式应权衡的问题。用模式应权衡的问题。 5 强大的通信和培训：许多机构拥有领先技术，可能正式通过强大的通信和培训：许多机构拥有领先技术，

5、可能正式通过了设计师论坛的论证或者非正式的公认专家。这些领先厂商了设计师论坛的论证或者非正式的公认专家。这些领先厂商将推广设计模式采用中的开放通信，并将培训开发具体设计将推广设计模式采用中的开放通信，并将培训开发具体设计模式的团队。模式的团队。 设计模式采用指导：设计模式可用于使项目受益，但是他们设计模式采用指导：设计模式可用于使项目受益，但是他们也可能因为误用而对应用程序造成损害。应当鼓励采用他们，也可能因为误用而对应用程序造成损害。应当鼓励采用他们，但是对其的采用应当受到审阅和验证。但是对其的采用应当受到审阅和验证。 重用实现重用实现,不只是设计模式不只是设计模式设计模式的本质是代码重用，

6、可以灵活把握设计模式的本质是代码重用，可以灵活把握 其他可重用的类（取决于公共实现）其他可重用的类（取决于公共实现） 缩短开发时间和降低成本缩短开发时间和降低成本 缩短维护时间和降低成本缩短维护时间和降低成本 在应用程序之间和内部轻松集成。在应用程序之间和内部轻松集成。 6 近年来，大家都开始注意设计模式。那么，到底近年来，大家都开始注意设计模式。那么，到底我们为什么要用设计模式呢？这么多设计模式为什么我们为什么要用设计模式呢？这么多设计模式为什么要这么设计呢？为什么要提倡要这么设计呢？为什么要提倡Design Pattern呢？呢？根本原因是为了代码复用，增加可维护性。那么怎么根本原因是为了

7、代码复用，增加可维护性。那么怎么才能实现代码复用呢？才能实现代码复用呢？OO界有前辈的几个原则：界有前辈的几个原则：开开闭闭原则原则(Open Closed Principal)、里氏代换原则、里氏代换原则、合成复用原则。设计模式就是实现了这些原则，从而合成复用原则。设计模式就是实现了这些原则，从而达到了代码复用、增加可维护性的目的。下面就简单达到了代码复用、增加可维护性的目的。下面就简单地介绍下几个基本的软件设计原则。地介绍下几个基本的软件设计原则。 7 定义：软件对扩展应该是开发的，对修改应该是关闭定义：软件对扩展应该是开发的，对修改应该是关闭的。更通俗的表达就是说开发一个软件时，应该可以

8、的。更通俗的表达就是说开发一个软件时，应该可以对它进行功能扩展（开放），而在进行这些扩展的时对它进行功能扩展（开放），而在进行这些扩展的时候，不需要对原来的程序进行修改（关闭）。候，不需要对原来的程序进行修改（关闭）。 好处：好处：在软件可用性上非常灵活。可以在软件完成对软件进行扩展，在软件可用性上非常灵活。可以在软件完成对软件进行扩展，加入新的功能。这样，这个软件就可以通过不断的增加新模加入新的功能。这样，这个软件就可以通过不断的增加新模块满足不断变化的新需求。块满足不断变化的新需求。由于对软件原来的模块不能修改，因此不用担心软件的稳定由于对软件原来的模块不能修改，因此不用担心软件的稳定性。

9、性。8 实现的主要原则：抽象，把系统的所有可能的行为抽实现的主要原则：抽象，把系统的所有可能的行为抽象成一个抽象底层象成一个抽象底层 ；同时由于可以从抽象层导出一；同时由于可以从抽象层导出一个或多个新的具体类可改变系统的行为，因此对于可个或多个新的具体类可改变系统的行为，因此对于可变的部分，系统设计对扩展是开放的。变的部分，系统设计对扩展是开放的。 可变性封装原则（可变性封装原则（EVP ）：对系统所有可能发生变）：对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独化的部分进行评估和分类，每一个可变的因素都单独进行封装进行封装 开闭原则很难被完全实现，只能在某些模块、某种程开闭

10、原则很难被完全实现，只能在某些模块、某种程度上、某个限度内符合度上、某个限度内符合OCP的要求，的要求，OCP具有理想具有理想主义的色彩，主义的色彩， 9 定义：就一个类而言，应该仅有一个引起它变化的原因。定义：就一个类而言，应该仅有一个引起它变化的原因。 职责即功能职责即功能 每一个引起类变化的原因就是一个职责，当一个类具有多个职责时，应该把多每一个引起类变化的原因就是一个职责，当一个类具有多个职责时，应该把多余的职责分离出去，分别再创建一些类来完成每一个职责余的职责分离出去，分别再创建一些类来完成每一个职责 每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化。每一个职责都是一

11、个变化的轴线，当需求变化时会反映为类的职责的变化。 举例举例 interface Moden public void dial(String pno); public void hangup(); public send(char c); public char recv(); Modem类具有两个职责：连接管理和数据通信，应将它们分离开来。类具有两个职责：连接管理和数据通信，应将它们分离开来。105.2.2 单一职责原则（单一职责原则（SRP） 对于变化的封装，应该遵循以下原则对于变化的封装，应该遵循以下原则 一个合理的类，应该仅有一个引起它变化的原因，即单一职一个合理的类，应该仅有一个引起

12、它变化的原因，即单一职责；责；在没有变化征兆的情况下应用在没有变化征兆的情况下应用SRP或其他原则是不明智的；或其他原则是不明智的；在需求实际发生变化时就应该应用在需求实际发生变化时就应该应用SRP等原则来重构代码；等原则来重构代码；使用测试驱动开发会迫使我们在设计出现臭味之前分离不合使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码；理代码；如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得如果测试不能迫使职责分离，僵化性和脆弱性的臭味会变得很强烈，那就应该用很强烈，那就应该用Facade或或Proxy模式对代码重构。模式对代码重构。115.2.3 listKov替换原则（替换原则

13、（LSP） 定义：定义：“继承必须确保超类所拥有的性质在子类中仍继承必须确保超类所拥有的性质在子类中仍然成立。然成立。”也就是说，当一个子类的实例应该能够替也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有换任何其超类的实例时，它们之间才具有is-A关系。关系。 LSP的本质：在同一个继承体系中的对象应该有共同的本质：在同一个继承体系中的对象应该有共同的行为特征。的行为特征。 例子：企鹅是鸟吗？例子：企鹅是鸟吗？ 生物学：企鹅属于鸟类生物学：企鹅属于鸟类LSP原则：企鹅不属于鸟类，因为企鹅不会原则：企鹅不属于鸟类，因为企鹅不会“飞飞” 违反违反LSP的后果：有可能需要修改

14、客户代码的后果：有可能需要修改客户代码125.2.3 listKov替换原则（替换原则（LSP） 确保对象行为和自身状态的方法确保对象行为和自身状态的方法 契约式设计契约式设计 （Design by Contract ）每个方法调用之前，该方法应该校验传入参数的正确性，只每个方法调用之前，该方法应该校验传入参数的正确性，只有正确才能执行该方法，否则认为调用方违反契约，不予执有正确才能执行该方法，否则认为调用方违反契约，不予执行行 一旦通过前置条件的校验，方法必须执行，并且必须确保执一旦通过前置条件的校验，方法必须执行，并且必须确保执行结果符合契约，这称之为后置条件行结果符合契约，这称之为后置条

15、件(Post-condition)。对象本身有一套对自身状态进行校验的检查条件，以确保该对象本身有一套对自身状态进行校验的检查条件，以确保该对象的本质不发生改变，这称之为不变式对象的本质不发生改变，这称之为不变式(Invariant)。135.2.4 依赖倒置原则（依赖倒置原则（DIP） 定义：高层模块不应该依赖于低层模块，二者都应该定义：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。依赖于抽象。 高层模块只应该包含重要的业务模型和策略选择，低层模块高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略实现。则是不同业务和策略实现。高层模块和低层模块都要抽象出来高层模块和

16、低层模块都要抽象出来高层抽象不依赖于高层和低层模块的具体实现，最多只依赖高层抽象不依赖于高层和低层模块的具体实现，最多只依赖于低层的抽象。于低层的抽象。低层的抽象和实现也只依赖于高层的抽象低层的抽象和实现也只依赖于高层的抽象 辅助原则辅助原则 任何变量都不应该持有一个指向具体类的引用。任何变量都不应该持有一个指向具体类的引用。 任何类都不应该从具体类派生。任何类都不应该从具体类派生。 任何方法都不应该覆盖它的任何基类中已经实现了的方法。任何方法都不应该覆盖它的任何基类中已经实现了的方法。 145.3 设计模式的类型设计模式的类型 在设计模式经典著作在设计模式经典著作GOF95中，设计模式从中，

17、设计模式从应用的角度被分为三个大的类型应用的角度被分为三个大的类型 15 创见型模式：用来创建对象的模式，抽象了实例化的过程创见型模式：用来创建对象的模式，抽象了实例化的过程 单件（单件（Singleton）模式：要求提供一种机制，保证一个类）模式：要求提供一种机制，保证一个类有且仅有一个实例，并且提供一个全局的访问点。有且仅有一个实例，并且提供一个全局的访问点。工厂方法（工厂方法（Factory Method）：父类负责定义创建对象的）：父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成

18、，是将类的实例化操作延迟到子类中完成， 即由子类来决定即由子类来决定究竟应该实例化（创建）哪一个类。究竟应该实例化（创建）哪一个类。抽象工厂（抽象工厂（Abstract Factory）：该模式为一个产品族提）：该模式为一个产品族提供了统一的创建接口。当需要这个产品族的某一系列的时供了统一的创建接口。当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类。厂类。16 创见型模式：用来创建对象的模式，抽象了实例化的过程创见型模式：用来创建对象的模式，抽象了实例化的过程 生成器模式（生成器模式（Builder）：将一个

19、复杂对象的构建与它的表）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。示分离，使得同样的构建过程可以创建不同的表示。Builder模式是一步一步创建一个复杂的对象，它允许用户模式是一步一步创建一个复杂的对象，它允许用户可以只通过指定复杂对象的类型和内容就可以构建它们，可以只通过指定复杂对象的类型和内容就可以构建它们，用户不知道内部的具体构建细节。用户不知道内部的具体构建细节。原型（原型（Prototype）模式：通过）模式：通过“复制复制”一个已经存在的一个已经存在的实例实例来返回新的实例来返回新的实例,而不是新建实例。被复制的实例就是而不是新建实例。被复制的实例

20、就是我们所称的我们所称的“原型原型”，这个原型是可定制的。原型模式多，这个原型是可定制的。原型模式多用于创建复杂的或者耗时的实例，因为这种情况下，复制用于创建复杂的或者耗时的实例，因为这种情况下，复制一个已经存在的实例使程序运行更高效；或者创建值相等，一个已经存在的实例使程序运行更高效；或者创建值相等，只是命名不一样的同类数据。只是命名不一样的同类数据。 17结构型设计模式结构型设计模式 ：结构型模式讨论的是类和对象的结构，：结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而实现新的功

21、能（对象结构型模式）。通过组合一些对象，从而实现新的功能（对象结构型模式）。合成（合成（Composite）模式：定义一个接口，使之可以用）模式：定义一个接口，使之可以用于单一对象，也可以应用于多个单一对象组成的对象组。于单一对象，也可以应用于多个单一对象组成的对象组。装饰（装饰（Decorator）模式：动态给一个对象添加一些额外）模式：动态给一个对象添加一些额外的职责，就好像给一个物体加上装饰物，完善其功能。的职责，就好像给一个物体加上装饰物，完善其功能。代理（代理（Proxy）模式：在软件系统中，有些对象有时候由）模式：在软件系统中，有些对象有时候由于跨越网络或者其他的障碍，而不能够或者

22、不想直接访于跨越网络或者其他的障碍，而不能够或者不想直接访问另一个对象，如果直接访问会给系统带来不必要的复问另一个对象，如果直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切，这就是中间层，让代理对象来代替目标对象打点一切，这就是代理（代理（Proxy）模式。）模式。18结构型设计模式结构型设计模式 ：结构型模式讨论的是类和对象的结构，它采用继承机：结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组合一些对象，从而制来组合接口或实现（类结

23、构型模式），或者通过组合一些对象，从而实现新的功能（对象结构型模式）。实现新的功能（对象结构型模式）。享元（享元（Flyweight）模式：）模式：Flyweight是一个共享对象，它可以同时是一个共享对象，它可以同时在不同上下文（在不同上下文（Context）使用，并在每个上下文中）使用，并在每个上下文中Flyweight都可都可以作为一个独立的对象。以作为一个独立的对象。外观（外观（Facade）模式：外观模式为子系统提供了一个更高层次、更）模式：外观模式为子系统提供了一个更高层次、更简单的接口，从而降低了子系统的复杂度和依赖。这使得子系统更简单的接口，从而降低了子系统的复杂度和依赖。这使

24、得子系统更易于使用和管理。外观是一个能为子系统和客户提供简单接口的类。易于使用和管理。外观是一个能为子系统和客户提供简单接口的类。当正确的应用外观，客户不再直接和子系统中的类交互，而是与外当正确的应用外观，客户不再直接和子系统中的类交互，而是与外观交互。外观承担与子系统中类交互的责任。观交互。外观承担与子系统中类交互的责任。桥梁（桥梁（Bridge）模式：桥梁模式的用意是将问题的抽象和实现分离）模式：桥梁模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题。开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题。适配器适配器(Adapter)模式：将一个模式

25、：将一个类类的接口适配成用户所期待的接口。的接口适配成用户所期待的接口。一个适配器允许通常因为接口不兼容而不能在一起工作的类工作在一个适配器允许通常因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包装在一个已存在的类中。一起，做法是将类自己的接口包装在一个已存在的类中。 19行为型模式：着力解决的是类实体之间的通讯关系，希望以面向对行为型模式：着力解决的是类实体之间的通讯关系，希望以面向对象的方式描述一个控制流程。象的方式描述一个控制流程。 模版方法（模版方法（Template Method）：定义了一个）：定义了一个算法算法的步骤，并的步骤，并允许子类别为一个或多个步骤提供

26、其实现方式。让子类别在不允许子类别为一个或多个步骤提供其实现方式。让子类别在不改变算法架构的情况下，重新定义算法中的某些步骤。改变算法架构的情况下，重新定义算法中的某些步骤。观察者（观察者（Observer）模式：定义了对象之间一对多的依赖，当）模式：定义了对象之间一对多的依赖，当这个对象的状态发生改变的时候，多个对象会接受到通知，有这个对象的状态发生改变的时候，多个对象会接受到通知，有机会做出反馈。机会做出反馈。迭代子（迭代子（Iterator）模式：提供一种方法顺序访问一个聚合对象）模式：提供一种方法顺序访问一个聚合对象中各个元素中各个元素, 而又不需暴露该对象的内部表示。而又不需暴露该对

27、象的内部表示。责任链（责任链（Chain of Responsibility）模式：在责任链模式里，）模式：在责任链模式里，很多对象由每一个对象对其下一个对象的引用而连接起来形成很多对象由每一个对象对其下一个对象的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使系统可以在不影响客户端的情况下动最终处理这个请求，这使系统可以在不影响客户端的情况下动态的重新组织链和分配责任。态的重新组织链和分配责任。20行为型模式：着力解决的是类实体之间的通讯关系，希行为型模式：着力解决的是类实体之间的通讯关系，希望以面向对象的方式描述一个控制流