标签：
一、
1、设计模式的定义 ：
设计模式(Design Pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
2、设计模式的基本要素 ：
设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式，其中的关键元素包括以下四个方面：
模式名称 (Pattern name)
问题 (Problem) ：需要解决的问题以及一些前提条件。
解决方案 (Solution) ：组成部分（类或对象）以及之间的相互关系，各自的职责和协作方式。
效果 (Consequences) ：第二章面向对象的设计原则
3、设计模式的分类：
根据其目的（模式是用来做什么的）可分为创建型(Creational)，结构型(Structural)和行为型(Behavioral)三种：
创建型模式主要用于创建对象。
结构型模式主要用于处理类或对象的组合。
行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。
根据范围，即模式主要是用于处理类之间关系还是处理对象之间的关系，可分为类模式和对象模式两种：
类模式处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，是属于静态的。
对象模式处理对象间的关系，这些关系在运行时刻变化，更具动态性。
4、设计模式的七个基本原则：
单一职责原则(Single Responsibility Principle, SRP)定义如下：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
开闭原则(Open-Closed Principle, OCP)定义如下：一个软件实体应当对扩展开放，对修改关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。
里氏代换原则：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
依赖倒转原则(Dependence Inversion Principle, DIP)的定义如下：高层模块不应该依赖低层模块，它们都应该依赖抽象。抽象不应该依赖于细节，细节应该依赖于抽象。
接口隔离原则(Interface Segregation Principle, ISP)的定义如下：客户端不应该依赖那些它不需要的接口。
合成复用原则(Composite Reuse Principle, CRP)又称为组合/聚合复用原则(Composition/ Aggregate Reuse Principle, CARP)，其定义如下：尽量使用对象组合，而不是继承来达到复用的目的。
迪米特法则：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
|
范围\目的 |
创建型模式 |
结构型模式 |
行为型模式 |
|
类模式 |
工厂方法模式 |
（类）适配器模式1 |
解释器模式 模板方法模式 |
|
对象模式 |
抽象工厂模式（t） 建造者模式(t) 原型模式 单例模式 |
（对象）适配器模式 桥接模式(t) 组合模式(t) 装饰模式(c) 外观模式 享元模式 代理模式 |
职责链模式(c) 命令模式(c) 迭代器模式 中介者模式 备忘录模式 观察者模式(c) 状态模式 策略模式(t) 访问者模式 |
5
二、
1、创建型模式： 简单工厂模式（Simple Factory）
工厂方法模式（Factory Method）
抽象工厂模式（Abstract Factory）
建造者模式（Builder）
原型模式（Prototype）
单例模式（Singleton）
2、简单工厂模式：
（1）模式定义：
简单工厂模式(Simple Factory Pattern)：又称为静态工厂方法(Static Factory Method) 模式，它属于类创建型模式。在简单工厂模式中，可以根据参数的不同返回不同 类的实例。简单工厂模式专门定义一个类来负责创建其他类的实例，被创建的 实例通常都具有共同的父类。
（2）动机：
考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆 形按钮、矩形按钮、菱形按钮等），这些按钮都源自同一个基类，不过在继承基类 后不同的子类修改了部分属性从而使得它们可以呈现不同的外观，如果我们希望在 使用这些按钮时，不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的 一个参数，并提供一个调用方便的方法，把该参数传入方法即可返回一个相应的按 钮对象，此时，就可以使用简单工厂模式。
（3）类图：
3、工厂方法模式：
（1）定义：
它属于类创建型模式。在工厂方法模式中，工厂父类负责定义创建产品对象 的 公共接口，而工厂子类则负责生成具体的产品对象，这样做的目的是将产品类的实 例化操作延迟到工厂子类中完成，即通过工厂子类来确定究竟应该实例化哪一个具 体产品类。
（2）动机：
在新增加一个具体产品类时，不修改工厂类的代码，而是将具体按钮的创建过程交 给专门的工厂子类去完成，我们先定义一个抽象的按钮工厂类，再定义具体的工 厂类来生成圆形按钮、矩形按钮、菱形按钮等，它们实现在抽象按钮工厂类中定义 的方法。这种抽象化的结果使这种结构可以在不修改具体工厂类的情况下引进新的 产品，如果出现新的按钮类型，只需要为这种新类型的按钮创建一个具体的工厂类 就可以获得该新按钮的实例，这一特点无疑使得工厂方法模式具有超越简单工厂模 式的优越性，更加符合“开闭原则”
（3）类图：
4、抽象工厂模式（重点复习类图）
（1）定义
提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象 工厂模式又称为Kit模式。
（2）动机
当系统所提供的工厂所需生产的具体产品并不是一个简单的对象，而是多个位于不 同产品等级结构中属于不同类型的具体产品时需要使用抽象工厂模式。
抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形态。
抽象工厂模式与工厂方法模式最大的区别在于，工厂方法模式针对的是一个产品等 级结构，而抽象工厂模式则需要面对多个产品等级结构，一个工厂等级结构可以负 责多个不同产品等级结构中的产品对象的创建 。当一个工厂等级结构可以创建出 分属于不同产品等级结构的一个产品族中的所有对象时，抽象工厂模式比工厂方法 模式更为简单、有效率。
（3）类图
模式结构：
（1）抽象工厂：抽象工厂用于声明生成抽象产品的方法，在一个抽象工厂中可以定义一组方法，每一个方法对应与一个产品等级结构
（2）具体工厂：具体工厂实现了抽象工厂声明了的生成抽象产品的方法，生成一组具体的产品，这些产品构成了一个产品族，每一个产品都位于某个产品等级结构中
（3）抽象产品：抽象产品为每种产品声明接口，再抽象产品中定义了产品的抽象业务方法
（4）具体产品定义具体工厂生产的具体产品对象，实现抽象接口中定义的业务方法
5、建造者模式
（1）定义：
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表 示。
（2）动机：
无论是在现实世界中还是在软件系统中，都存在一些复杂的对象，它们拥有多个组 成部分，如汽车，它包括车轮、方向盘、发送机等各种部件。而对于大多数用户而 言，无须知道这些部件的装配细节，也几乎不会使用单独某个部件，而是使用一辆 完整的汽车，可以通过建造者模式对其进行设计与描述，建造者模式可以将部件和 其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型 就可以得到该对象，而无须知道其内部的具体构造细节。
复杂对象相当于一辆有待建造的汽车，而对象的属性相当于汽车的部件，建造产品 的过程就相当于组合部件的过程。由于组合部件的过程很复杂，因此，这些部件的 组合过程往往被“外部化”到一个称作建造者的对象里，建造者返还给客户端的是 一个已经建造完毕的完整产品对象，而用户无须关心该对象所包含的属性以及它们 的组装方式，这就是建造者模式的模式动机。
（3）类图：
6、原型模式
（1）定义：
原型模式是一种对象创建型模式，用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。原型模式允许一个对象再创建另外一个可定制的对象，无须知道任何创建的细节。
（2）动机：
在面向对象系统中，使用原型模式来复制一个对象自身，从而克隆出多个与原型对 象一模一样的对象。
在软件系统中，有些对象的创建过程较为复杂，而且有时候需要频繁创建，原型模 式通过给出一个原型对象来指明所要创建的对象的类型，然后用复制这个原型对象 的办法创建出更多同类型的对象，这就是原型模式的意图所在。
（3）类图：
7、单例模式
（1）定义：
单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例， 这个类称为单例类，它提供全局访问的方法。
（2）动机：
对于系统中的某些类来说，只有一个实例很重要，定义一个全局变量可以确保对象 随时都可以被访问，但不能防止我们实例化多个对象。一个更好的解决办法是让类 自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建，并且它可以提 供一个访问该实例的方法。这就是单例模式的模式动机
（3）类图：
8、适配器模式
（1）定义
将一个接口转换成客户希望的另一个接口，适配器模式使接口不兼容的那些类可以 一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也 可以作为对象结构型模式。
（2）动机
适配器提供客户类需要的接口，适配器的实现就是把客户类的请求转化为对适配者 的相应接口的调用。当客户类调用适配器的方法时，在适配器类的内部将调用适配 者类的方法，而这个过程对客户类是透明的，客户类并不直接访问适配者类。因此， 适配器可以使由于接口不兼容而不能交互的类可以一起工作。这就是适配器模式的 模式动机。
（3）类图
9、桥接模式（重点复习：类图）
（1）定义
将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型 模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。
（2）动机
设想如果要绘制矩形、圆形、椭圆、正方形，我们至少需要4个形状类，但是如果 绘制的图形需要具有不同的颜色，如红色、绿色、蓝色等，此时至少有如下两种设 计方案：
第一种设计方案是为每一种形状都提供一套各种颜色的版本。
第二种设计方案是根据实际需要对形状和颜色进行组合。
对于有两个变化维度（即两个变化的原因）的系统，采用方案二来进行设计系统中 类的个数更少，且系统扩展更为方便。设计方案二即是桥接模式的应用。桥接模式 将继承关系转换为关联关系，从而降低了类与类之间的耦合，减少了代码编写量
（3）类图
10、组合模式（重点复习：类图）
（1）定义
组合多个对象形成树形结构以表示“整体-部分”的结构层次。组合模式对单个对 象（即叶子对象）和组合对象（即容器对象）的使用具有一致性。 属于对象的结 构模式
（2）动机
对于树形结构，当容器对象（如文件夹）的某一个方法被调用时，将遍历整个树形 结构，寻找也包含这个方法的成员对象（可以是容器对象，也可以是叶子对象，如 子文件夹和文件）并调用执行。（递归调用）
由于容器对象和叶子对象在功能上的区别，在使用这些对象的客户端代码中必须有 区别地对待容器对象和叶子对象，而实际上大多数情况下客户端希望一致地处理它 们，因为对于这些对象的区别对待将会使得程序非常复杂。
组合模式描述了如何将容器对象和叶子对象进行递归组合，使得用户在使用时无须 对它们进行区分，可以一致地对待容器对象和叶子对象，这就是组合模式的模式动 机。
（3）类图
11、装饰模式（代码！！！）
（1）定义
动态地给一个对象增加一些额外的职责(Responsibility)，就增加对象功能来说，装 饰模式比生成子类实现更为灵活。其别名也可以称为包装器(Wrapper)，与适配器 模式的别名相同，但它们适用于不同的场合。根据翻译的不同，装饰模式也有人称 之为“油漆工模式”，它是一种对象结构型模式。
（2）动机：
装饰模式以对客户透明的方式动态地给一个对象附加上更多的责任，换言之，客户 端并不会觉得对象在装饰前和装饰后有什么不同。装饰模式可以在不需要创造更多 子类的情况下，将对象的功能加以扩展。这就是装饰模式的模式动机。
（3）类图
13、外观模式
（1）定义
外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接 口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统 更加容易使用。外观模式又称为门面模式，它是一种对象结构型模式。
（2）动机
引入外观角色之后，用户只需要直接与外观角色交互，用户与子系统之间的复杂关 系由外观角色来实现，从而降低了系统的耦合度。
（3）类图
12、享元模式
（1）定义
运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些 对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够 共享的对象必须是细粒度对象，因此它又称为轻量级模式，它是一种对象结构型模 式。
（2）动机
在享元模式中可以共享的相同内容称为内部状态(Intrinsic State)，而那些需要外部 环境来设置的不能共享的内容称为外部状态(Extrinsic State)，由于区分了内部状态 和外部状态，因此可以通过设置不同的外部状态使得相同的对象可以具有一些不同 的特征，而相同的内部状态是可以共享的。
在享元模式中通常会出现工厂模式，需要创建一个享元工厂来负责维护一个享元池 (Flyweight Pool)用于存储具有相同内部状态的享元对象。
享元对象一般都设计为较小的对象，它所包含的内部状态较少，这种对象也称为细 粒度对象。享元模式的目的就是使用共享技术来实现大量细粒度对象的复用
（3）类图
13、代理模式
（1）定义
给某一个对象提供一个代理，并由代理对象控制对原对象的引用。代理模式的英文 叫做Proxy或Surrogate，它是一种对象结构型模式。
（2）动机
通过引入一个新的对象（如小图片和远程代理对象）来实现对真实对象的操作或者 将新的对象作为真实对象的一个替身，这种实现机制即为代理模式，通过引入代理 对象来间接访问一个对象，这就是代理模式的模式动机。
（3）类图
14、职责链模式（代码！！！）
（1）定义
避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象 连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。由于英文翻译 的不同，职责链模式又称为责任链模式，它是一种对象行为型模式
（2）动机
职责链可以是一条直线、一个环或者一个树形结构，最常见的职责链是直线型，即 沿着一条单向的链来传递请求。
链上的每一个对象都是请求处理者，职责链模式可以将请求的处理者组织成一条链， 并使请求沿着链传递，由链上的处理者对请求进行相应的处理，客户端无须关心请 求的处理细节以及请求的传递，只需将请求发送到链上即可，将请求的发送者和请 求的处理者解耦。这就是职责链模式的模式动机
（3）类图
15、命令模式（代码！！！）
（1）定义
将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请 求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模 式，其别名为动作(Action)模式或事务(Transaction)模式。
（2）动机
命令模式可以对发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系， 发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。这就是命令 模式的模式动机
（3）类图
16、解释器模式
（1）定义
定义语言的文法，并且建立一个解释器来解释该语言中的句子，这里的“语言” 意思是使用规定格式和语法的代码，它是一种类行为型模式。
（2）动机
如果在系统中某一特定类型的问题发生的频率很高，此时可以考虑将这些问题的实 例表述为一个语言中的句子，因此可以构建一个解释器，该解释器通过解释这些句 子来解决这些问题。
解释器模式描述了如何构成一个简单的语言解释器，主要应用在使用面向对象语言 开发的编译器中。
（3）类图
17、迭代器模式
（1）定义
提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标 (Cursor)。迭代器模式是一种对象行为型模式
（2）动机
一个聚合对象，如一个列表(List)或者一个集合(Set)，应该提供一种方法来让别人可 以访问它的元素，而又不需要暴露它的内部结构。
针对不同的需要，可能还要以不同的方式遍历整个聚合对象，但是我们并不希望在 聚合对象的抽象层接口中充斥着各种不同遍历的操作。
怎样遍历一个聚合对象，又不需要了解聚合对象的内部结构，还能够提供多种不同 的遍历方式，这就是迭代器模式所要解决的问题。
在迭代器模式中，提供一个外部的迭代器来对聚合对象进行访问和遍历，迭代器定 义了一个访问该聚合元素的接口，并且可以跟踪当前遍历的元素，了解哪些元素已 经遍历过而哪些没有
（3）类图
18、中介者模式
（1）定义
用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用， 从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式又称为调停 者模式，它是一种对象行为型模式
（2）动机
在面向对象的软件设计与开发过程中，根据“单一职责原则”，我们应该尽量将对 象细化，使其只负责或呈现单一的职责。
对于一个模块，可能由很多对象构成，而且这些对象之间可能存在相互的引用，为 了减少对象两两之间复杂的引用关系，使之成为一个松耦合的系统，我们需要使用 中介者模式，这就是中介者模式的模式动机。
（3）类图
19、备忘录模式
(1)定义
在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它是一种对象行为型模式，其别名为Token
(2)动机
在应用软件的开发过程中，很多时候我们都需要记录一个对象的内部状态。
在具体实现过程中，为了允许用户取消不确定的操作或从错误中恢复过来，需要实现备份点和撤销机制，而要实现这些机制，必须事先将状态信息保存在某处，这样才能将对象恢复到它们原先的状态。
备忘录模式是一种给我们的软件提供后悔药的机制，通过它可以使系统恢复到某一特定的历史状态。
(3)类图
20、观察者模式
(1)定义
观察者模式(Observer Pattern)：定义对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。
(2)动机
建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应做出反应。在此，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间没有相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展，这就是观察者模式的模式动机。
(3)类图
21、状态模式
(1)定义
允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。
(2)动机
在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的 (stateful)对象，这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。
在UML中可以使用状态图来描述对象状态的变化。
(3)类图
22、策略模式
(1)定义
定义一系列算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化，也称为政策模式(Policy)。策略模式是一种对象行为型模式。
(2)动机
除了提供专门的查找算法类之外，还可以在客户端程序中直接包含算法代码，这种做法更不可取，将导致客户端程序庞大而且难以维护，如果存在大量可供选择的算法时问题将变得更加严重。
为了解决这些问题，可以定义一些独立的类来封装不同的算法，每一个类封装一个具体的算法，在这里，每一个封装算法的类我们都可以称之为策略(Strategy)，为了保证这些策略的一致性，一般会用一个抽象的策略类来做算法的定义，而具体每种算法则对应于一个具体策略类。
(3)类图
23、模板方法模式
(1)定义
定义一个操作中算法的骨架，而将一些步骤延迟到子类中，模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。模板方法是一种类行为型模式
(2)动机
模板方法模式是基于继承的代码复用基本技术，模板方法模式的结构和用法也是面向对象设计的核心之一。在模板方法模式中，可以将相同的代码放在父类中，而将不同的方法实现放在不同的子类中。
在模板方法模式中，我们需要准备一个抽象类，将部分逻辑以具体方法以及具体构造函数的形式实现，然后声明一些抽象方法来让子类实现剩余的逻辑。不同的子类可以以不同的方式实现这些抽象方法，从而对剩余的逻辑有不同的实现，这就是模板方法模式的用意。模板方法模式体现了面向对象的诸多重要思想，是一种使用频率较高的模式
(3)类图
24、访问者模式
(1)定义
表示一个作用于某对象结构中的各元素的操作，它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式是一种对象行为型模式。
(2)动机
在实际使用时，对同一集合对象的操作并不是唯一的，对相同的元素对象可能存在多种不同的操作方式。
而且这些操作方式并不稳定，可能还需要增加新的操作，以满足新的业务需求。
此时，访问者模式就是一个值得考虑的解决方案。
访问者模式的目的是封装一些施加于某种数据结构元素之上的操作，一旦这些操作需要修改的话，接受这个操作的数据结构可以保持不变。为不同类型的元素提供多种访问操作方式，且可以在不修改原有系统的情况下增加新的操作方式，这就是访问者模式的模式动机。
(3)类图
注：所用类图均来自课堂ppt类图，非本人原创
标签：
原文地址：http://www.cnblogs.com/laozhanghahaha/p/5096862.html
