7.1 设计模式概述
重复遇到的典型问题，描述这些共同问题 和 解决这些问题的方案 就形成了所谓的 模式。
7.1.1 设计模式的历史
模式分为几个部分：
特定的情景（Context），指模式在 何种情况下发生作用；
动机（System of Force），指问题或预期的目标；
解决方案（Solution），平衡各动机 或 解决所阐述问题的 构造或配置。
每个模式描述了一个在某种特定情境下不断重复发生的问题，以及解决该问题解决方案的核心所在。
7.1.2 为什么要使用设计模式
面向对象设计时需要考虑 封装性、力度大小、依赖关系、灵活性、可重用性 等。
1、简化并加快快设计
无需从底层做起，重用成功的设计，节约开发时间，提高软件质量。
2、方便开发人员之间的通信
可以更准确地 描述问题 及 问题的解决方案，使解决方案具有一致性。
3、降低风险
4、有助于转到面向对象技术
开发人员对新技术往往会有抵触或排斥心理，对新技术可能带来的效果持怀疑态度。
成熟的设计模式具有以下特性：
1.巧妙。
2.通用，不依赖于 系统、语言、领域。
3.不仅仅停留在理论上。
4.简单。
5.可重用。
6.面向对象。
7.1.3 设计模式的组成元素
1、模式名，简洁地描述了 模式的本质，可以帮助我们思考。
2、问题或意图，解释了设计问题和问题存在的前因后果，可能描述了特定的设计问题。
3、情景，告诉我们该模式的适用性。
4、动机，描述相关的动机和约束，通常需要对各期望的目标进行有限排序，动机阐明了问题的复杂性，定义了在相互冲突时所采取的各种权衡手段。
5、解决方案，因为模式就像一个模板，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的 抽象描述 和怎样用一个 具有一般意义的 元素组合。
6、示例，帮助读者理解模式的具体使用方法。
7、结果情景，阐述了模式后续状态和副作用。
8、基本原理，解释该模式 如何、为何 能解决当前问题。
9、相关模式，包括 静态的 和 动态的，迁到模式、后续模式、替代模式。
10、已知应用，通常好的模式前面都有一个摘要，提供简短的总结和概述，为模式描绘出一个清晰的图画，提供有关该模式能够解决问题的快速信息。
模式应该说明它的目标读者，以及对读者有哪些知识要求。
7.1.4 设计模式的分类
软件模式 主要可分为 设计模式、分析模式、组织和过程模式 等。
设计模式主要用于 得到简洁灵活的 系统设计。
按设计模式的目的划分，创建型、结构型、行为型；
按设计模式范围划分，类设计模式、对象设计模式。
1、创建型模式，对对象实例化过程的 抽象，采用抽象类所定义的接口，封装了对象如何创建、组合 等信息。
2、结构型模式，如何组合已有的类和对象 以及获得更大的结构。
3、行为型模式，不仅描述对象或类的模式，还描述它们之间的通信模式，特别是描述一组 对等的对象怎样互相协作 完成其中任一对象 无法单独完成的任务。
7.2 设计模式实例
7.2.1 创建性模式
通过该了的子类来创建对象的。但是，这可能会 限制在系统内创建对象的 类型或数目。
1、Abstract Factory 模式
在不指定具体类的情况下，为创建一些列 相关 或 相互依赖的对象提供了接口。
提供了一个可以 确定合适的具体类 的抽象类。
优点：
可以与具体类分开。
更容易在产品系列中转换。
提高了产品间的一致性。
以下情况应该使用 Abstract Factory 模式：
系统独立于产品的 创建、组成、表示。
系统配置成 具有多个产品的 系列。
相关产品对象系列 是共同使用的，而且必须确保这一点。
你希望提供产品的类库，只开放其接口。
2、Builder 模式
将复杂对象的 构件与表示 相分离，相同的构造过程可以创建不同的对象，通过只指定对象的 类型和内容。
一次就可以创建所有的复杂对象，而其他模式一次就只能创建一个对象。
优点：
可以对产品内部表示进行改变。
将构造代码与表示代码相分离。
以下情况应该使用 Builder 模式：
算法独立于 组成对象。
构造过程必须允许已构件对象有不同表示。
3、Factory Method 模式
实例化工作交给其子类，可以在不修改代码的情况下引入新类，因为新类只实现了接口。
优点：
代码只处理接口，因此可以使用任何实现了接口的类。
在类中创建对象比直接在客户端创建要更加灵活。
以下情况中，应该使用 Factory Method 模式：
类不能预料它必须创建的对象的类。
类希望其子类指定要创建的对象。
类将责任转给某个帮助子类，而用户希望定位那个被授权的帮助子类。
4、Prototype 模式
只要将对象类定义成能够复制自身就可以实现。
优点如下：
可以在运行时 添加或删除产品。
通过改变值 指定新对象。
通过改变结构 制定新对象。
减少子类的生成和使用。
可以用类 动态地配置 应用程序。
以下情况中，应该使用 Prototype 模式：
运行时，指定需要实例化的类，例如动态载入。
避免构建与产品的类层次结构相似的 工厂类层次结构。
5、Singleton 模式
确保 一个类只有一个实例，并且提供全局访问入口，确保使用这个 实例 所有的对象 使用相同的实例。
优点：
对单个实例的受控访问。
命名空间的减少。
允许改进操作和表示。
允许改变数目的实例。
比类操作更灵活。
7.2.2 结构性模式
机构性模式 控制 较大部分之间的 关系。
它将以不同的方式 影响应用程序。
允许在补充写代码或自定义代码的情况下 创建系统。
具有增强的 重复使用性和应用性能。
1、Adapter 模式
可以充当两个类之间的媒介，可以转换一个类的接口，被另外一个类使用，使得具有不兼容接口的类能够系统使用。
优点：
允许 多个 不兼容的对象 进行交互和通信。
提高已有功能的 重复使用性。
以下情况，应该使用 Adapter 模式：
要使用已有类，而该类接口与所需的接口并不匹配。
要创建可重用的类，该类可以与 不相关 或 未知类 进行协作。
要在一个 不同于已知对象接口的接口环境中 使用对象。
必须要进行多个源之间的接口转换的时候。
2、Bridge模式
将一个复杂的组件 分成两个独立的 但又相关的 继承层次结构：功能性抽象和内部实现。
优点：
接口与实现相分离。
提高了可扩展性。
对客户端隐藏了实现的细节。
以下情况中，应该使用 Bridge 模式：
避免在抽象及其实现之间 存在永久的绑定。
抽象及其实现 可以使用子类进行扩展。
抽象的实现被改动 不用重新编译代码。
3、Composite 模式
创建树形层次结构来改变复杂性。
优点：
定义了由 主要对象 和 符合对象 组成的类层次结构。
添加新的组件类型更加简单。
结构的灵活性 和 可管理性的接口。
以下情况中，应该使用 Composite 模式：
想要表示对象的整个 或者部分的层次结构。
想要客户端能够忽略符合对象和单个对象之间的差异。
结构可以具有任何级别的复杂性，而且是动态的。
4、Decorator 模式
不修改对象外观和功能的情况下 添加或删除对象功能。
优点：
比静态继承具有更大的灵活性。
避免了特征装载的类 处于层次结构的 过高级别。
简化了编码。
改进了对象的扩展性。
在以下情况中，应该使用 Decorator 模式：
在单个对象中 动态并且透明地 添加责任，不会影响其他对象。
以后可能要修改的对象中添加责任。
无法通过静态子类化实现扩展时。
5、Facade 模式
为子系统中的一组接口 提供了一个统一的接口。更容易使用子系统的高级接口。
优点：
在不减少系统所提供的选项的情况下，为复杂系统提供了简单接口。
屏蔽了子系统组件。
提高若耦合度。
将客户端请求转换后 发送给能够处理这些请求的 子系统。
以下情况中，应使用 Facade 模式：
为复杂的子系统提供简单的接口。
客户端和抽象的实现类中 存在许多依赖关系。
想要对子系统进行分层。
6、Flyweight 模式
通过共享对象 减少对象数目。
通过共享一个接口来避免使用多个具有相同信息的实例 所带来的开销。
优点：
减少了要处理的对象数目。
如果对象能够持续，可以减少内存和存储设备。
以下情况中，应该使用 Flyweight 模式：
应用程序使用大量的对象。
由于对象数目巨大，导致很高的存储开销。
不依赖于对象的身份。
7.2.3 行为性模式
行为性模式 影响 系统的 状态、行为流。
简化、优化 并且 提高应用程序的 可维护性。
1、Chain of Responsibility 模式
在系统中建立一个链，在首先接收到它的级别处 被处理，或者定位到可以处理它的对象。
优点：
降低了耦合度。
增加面向对象制定责任的 灵活性。
类的集合可以作为一个整体。
以下情况中，应该使用 Chain of Responsibility 模式：
多个对象可以处理一个请求，而其处理器却是未知的。
在不指定确切的 请求接受对象的情况下，向几个对象中的 一个 发送请求。
动态地指定能够处理请求的对象集。
2、Command 模式
在对象中封装了请求。
优点：
将调用操作的对象 与 知道如何完成该操作的对象 相分离。
更容易添加新指令，因为不用修改已有类。
以下情况中，应该使用 Command 模式：
要通过执行的动作 来 参数化对象。
在不同的时间 指定、排序、执行 请求。
必须支持 Undo、日志记录 或 事务。
3、Interpreter 模式
解释定义其语法表示的语言，提供了语句解释器。
优点：
容易修改并扩展语法。
更容易实现语法。
以下情况中，应该使用 Interpreter 模式：
语言的语法比较简单。
效率并不是最主要的问题。
4、Iterator 模式
为集合中的有序访问提供了一致的方法，而该集合是独立于基础集合。
优点：
支持集合的不同遍历。
简化了集合的接口。
以下情况中，应该使用 Iterator 模式：
不开放集合对象内部表示的前提下，访问集合对象内容。
支持集合对象的多重遍历。
为遍历集合中的不同结构 提供了统一的接口。
5、Mediator 模式
通过引入一个能够管理对象间消息分布的对象，简化了系统中对象间的通信。提高了对象间的松耦合度，还可以独立地 改变 其间的交互。
优点：
去除对象间的影响。
简化了对象间协议。
集中化了控制。
由于不再需要直接互传消息，单个组件变得更加简单，而且容易处理。
由于不再需要 包含逻辑 来处理组件间的通信，组件变得更加通用。
以下情况中，应该使用 Mediator 模式：
对象集合需要以 一个定义规范但复杂的方式 进行通信。
6、Memento 模式
保持对象状态的“快照”（snapshot），对象可以在不向外界公开其内容的情况下 返回到它的最初状态。
优点：
保持封装的完整性。
简化了返回到初始状态所需的操作。
以下情况中，应该使用 Memento 模式：
必须保存对象状态的快照，恢复状态。
7、Observer 模式
定义了对象间 一到多 的依赖关系，当对象改变状态时，将自动通知 并 更新它所有的依赖对象。
优点：
抽象了主题与 Observer 之间的耦合关系。
支持广播方式通信。
以下情况中，应该使用 Observer 模式：
对一个对象的修改 涉及对其他对象的修改，而且不知道有多少对象 需要进行相应修改。
对象应该能够 在不同假设对象标识的前提下 通知其它对象。
8、State 模式
对象在内部状态变化时，变更其行为，并且修改其类。
优点：
针对不同状态来划分行为，使状态转换显式进行。
9、Strategy 模式
定义了一组能够用来表示 可能行为集合的类。这些行为 可以在应用程序中使用，来修改应用程序功能。
优点：
另一种子类化方法。
在类自身中定义了 每一个行为，减少了条件语句。
更容易扩展模型。
以下情况中，应该使用 Strategy 模式：
许多相关类 只是在行为方面有所区别。
需要算法的不同变体。
算法使用客户端未知的数据。
10、Template Method 模式
不重写方法的前提下 允许 子类重载部分方法 的方法。
将一些步骤由子类实现。
优点：代码重用的基础技术。
以下情况中，应该使用 Template Method 模式：
一次实现算法的不变部分，子类实现算法的可变行为。
11、Visitor 模式
不改变操作元素的类 的前提下 定义一个新操作。
优点：
容易添加新操作。
集中相关 排除不相关 操作。
以下情况中，应该使用 Visitor 模式：
包含许多具有不同接口的对象类，并且想要对这些 依赖具体类的对象进行操作。
定义对象结构的类很少被修改，但想要在此结构上定义新的操作。