设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理地运用设计模式可以完美地解决很多问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被广泛应用的原因。
设计模式的类型
共有 23 种设计模式。这些模式可以分为三大类：
- 创建型模式（Creational Patterns）- 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
- 结构型模式（Structural Patterns）- 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。
- 行为型模式（Behavioral Patterns）- 这些设计模式特别关注对象之间的通信。
- 责任链模式（Chain of Responsibility Pattern）
- 命令模式（Command Pattern）
- 解释器模式（Interpreter Pattern）
- 迭代器模式（Iterator Pattern）
- 中介者模式（Mediator Pattern）
- 备忘录模式（Memento Pattern）
- 观察者模式（Observer Pattern）
- 状态模式（State Pattern）
- 空对象模式（Null Object Pattern）
- 策略模式（Strategy Pattern）
- 模板模式（Template Pattern）
- 访问者模式（Visitor Pattern）
- 规格模式 *（Specification）
- 访问者模式 *（Visitor）
- J2EE 设计模式 - 这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。
下面用一个图片来整体描述一下设计模式之间的关系：
设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭 。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成 / 聚合的方式，而不是使用继承。
工厂模式
工厂模式（Factory Pattern）最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。
介绍
意图： 定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。
主要解决： 主要解决接口选择的问题。
何时使用： 我们明确地计划不同条件下创建不同实例时。
如何解决： 让其子类实现工厂接口，返回的也是一个抽象的产品。
关键代码： 创建过程在其子类执行。
应用实例：
- 您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。
- Hibernate 换数据库只需换方言和驱动就可以。
优点：
- 一个调用者想创建一个对象，只要知道其名称就可以了。
- 扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。
- 屏蔽产品的具体实现，调用者只关心产品的接口。
缺点： 每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。
使用场景：
- 日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。
- 数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。
- 设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。
注意事项： 作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。
抽象工厂模式
抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
介绍
意图： 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
主要解决： 主要解决接口选择的问题。
何时使用： 系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。
如何解决： 在一个产品族里面，定义多个产品。
关键代码： 在一个工厂里聚合多个同类产品。
应用实例： 工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OO 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。
优点： 当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。
缺点： 产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。
使用场景：
- QQ 换皮肤，一整套一起换。
- 生成不同操作系统的程序。
注意事项： 产品族难扩展，产品等级易扩展。
单例模式
单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。
注意：
- 1、单例类只能有一个实例。
- 2、单例类必须自己创建自己的唯一实例。
- 3、单例类必须给所有其他对象提供这一实例。
介绍
意图： 保证一个类仅有一个实例，并提供一个访问它的全局访问点。
主要解决： 一个全局使用的类频繁地创建与销毁。
何时使用： 当您想控制实例数目，节省系统资源的时候。
如何解决： 判断系统是否已经有这个单例，如果有则返回，如果没有则创建。
关键代码： 构造函数是私有的。
应用实例：
- 一个班级只有一个班主任。
- Windows 是多进程多线程的，在操作一个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象，所以所有文件的处理必须通过唯一的实例来进行。
- 一些设备管理器常常设计为单例模式，比如一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。
优点：
- 在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。
- 避免对资源的多重占用（比如写文件操作）。
缺点： 没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。
使用场景：
- 要求生产唯一序列号。
- WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。
- 创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。
注意事项：getInstance() 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成 instance 被多次实例化。
建造者模式
建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其他对象的。
介绍
意图： 将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
主要解决： 主要解决在软件系统中，有时候面临着 "一个复杂对象" 的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。
何时使用： 一些基本部件不会变，而其组合经常变化的时候。
如何解决： 将变与不变分离开。
关键代码： 建造者：创建和提供实例，导演：管理建造出来的实例的依赖关系。
应用实例：
- 去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是经常变化的，生成出所谓的 "套餐"。
- JAVA 中的 StringBuilder。
优点：
- 建造者独立，易扩展。
- 便于控制细节风险。
缺点：
- 产品必须有共同点，范围有限制。
- 如内部变化复杂，会有很多的建造类。
使用场景：
- 需要生成的对象具有复杂的内部结构。
- 需要生成的对象内部属性本身相互依赖。
注意事项： 与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。
原型模式
原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。
这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。
介绍
意图： 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
主要解决： 在运行期建立和删除原型。
何时使用：
- 当一个系统应该独立于它的产品创建，构成和表示时。
- 当要实例化的类是在运行时刻指定时，例如，通过动态装载。
- 为了避免创建一个与产品类层次平行的工厂类层次时。
- 当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
如何解决： 利用已有的一个原型对象，快速地生成和原型对象一样的实例。
关键代码：
- 实现克隆操作，在 JAVA 继承 Cloneable，重写 clone()，在 .NET 中可以使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。
- 原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些 "易变类" 拥有稳定的接口。
应用实例：
- 细胞分裂。
- JAVA 中的 Object clone() 方法。
优点：
- 性能提高。
- 逃避构造函数的约束。
缺点：
- 配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。
- 必须实现 Cloneable 接口。
使用场景：
- 资源优化场景。
- 类初始化需要消化非常多的资源，这个资源包括数据. 硬件资源等。
- 性能和安全要求的场景。
- 通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。
- 一个对象多个修改者的场景。
- 一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。
- 在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。
注意事项： 与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的。浅拷贝实现 Cloneable，重写，深拷贝是通过实现 Serializable 读取二进制流。
对象池模式
对象池（也称为资源池）被用来管理对象缓存。对象池是一组已经初始化过且可以直接使用的对象集合，用户在使用对象时可以从对象池中获取对象，对其进行操作处理，并在不需要时归还给对象池而非销毁它。
若对象初始化、实例化的代价高，且需要经常实例化，但每次实例化的数量较少的情况下，使用对象池可以获得显著的性能提升。常见的使用对象池模式的技术包括线程池、数据库连接池、任务队列池、图片资源对象池等。
当然，如果要实例化的对象较小，不需要多少资源开销，就没有必要使用对象池模式了，这非但不会提升性能，反而浪费内存空间，甚至降低性能。
示例代码
Pool.php
<?php
namespace DesignPatterns\Creational\Pool;
class Pool
{
private $instances = array();
private $class;
public function __construct($class)
{
$this->class = $class;
}
public function get()
{
if (count($this->instances) > 0) {
return array_pop($this->instances);
}
return new $this->class();
}
public function dispose($instance)
{
$this->instances[] = $instance;
}
}
Processor.php
<?php
namespace DesignPatterns\Creational\Pool;
class Processor
{
private $pool;
private $processing = 0;
private $maxProcesses = 3;
private $waitingQueue = [];
public function __construct(Pool $pool)
{
$this->pool = $pool;
}
public function process($image)
{
if ($this->processing++ < $this->maxProcesses) {
$this->createWorker($image);
} else {
$this->pushToWaitingQueue($image);
}
}
private function createWorker($image)
{
$worker = $this->pool->get();
$worker->run($image, array($this, 'processDone'));
}
public function processDone($worker)
{
$this->processing--;
$this->pool->dispose($worker);
if (count($this->waitingQueue) > 0) {
$this->createWorker($this->popFromWaitingQueue());
}
}
private function pushToWaitingQueue($image)
{
$this->waitingQueue[] = $image;
}
private function popFromWaitingQueue()
{
return array_pop($this->waitingQueue);
}
}
Worker.php
<?php
namespace DesignPatterns\Creational\Pool;
class Worker
{
public function __construct()
{
// let's say that constuctor does really expensive work...
// for example creates "thread"
}
public function run($image, array $callback)
{
// do something with $image...
// and when it's done, execute callback
call_user_func($callback, $this);
}
}
多例模式
多例模式和单例模式类似，但可以返回多个实例。比如我们有多个数据库连接，MySQL、SQLite、Postgres，又或者我们有多个日志记录器，分别用于记录调试信息和错误信息，这些都可以使用多例模式实现。
示例代码
Multiton.php
<?php
namespace DesignPatterns\Creational\Multiton;
/**
* Multiton类
*/
class Multiton
{
/**
*
* 第一个实例
*/
const INSTANCE_1 = '1';
/**
*
* 第二个实例
*/
const INSTANCE_2 = '2';
/**
* 实例数组
*
* @var array
*/
private static $instances = array();
/**
* 构造函数是私有的，不能从外部进行实例化
*
*/
private function __construct()
{
}
/**
* 通过指定名称返回实例（使用到该实例的时候才会实例化）
*
* @param string $instanceName
*
* @return Multiton
*/
public static function getInstance($instanceName)
{
if (!array_key_exists($instanceName, self::$instances)) {
self::$instances[$instanceName] = new self();
}
return self::$instances[$instanceName];
}
/**
* 防止实例从外部被克隆
*
* @return void
*/
private function __clone()
{
}
/**
* 防止实例从外部反序列化
*
* @return void
*/
private function __wakeup()
{
}
}
静态工厂模式
与简单工厂类似，该模式用于创建一组相关或依赖的对象，不同之处在于静态工厂模式使用一个静态方法来创建所有类型的对象，该静态方法通常是 factory 或 build。
示例代码
StaticFactory.php
<?php
namespace DesignPatterns\Creational\StaticFactory;
class StaticFactory
{
/**
* 通过传入参数创建相应对象实例
*
* @param string $type
*
* @static
*
* @throws \InvalidArgumentException
* @return FormatterInterface
*/
public static function factory($type)
{
$className = __NAMESPACE__ . '\Format' . ucfirst($type);
if (!class_exists($className)) {
throw new \InvalidArgumentException('Missing format class.');
}
return new $className();
}
}
FormatterInterface.php
<?php
namespace DesignPatterns\Creational\StaticFactory;
/**
* FormatterInterface接口
*/
interface FormatterInterface
{
}
FormatString.php
<?php
namespace DesignPatterns\Creational\StaticFactory;
/**
* FormatNumber类
*/
class FormatNumber implements FormatterInterface
{
}
适配器模式
适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。
这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。
介绍
意图： 将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
主要解决： 主要解决在软件系统中，常常要将一些 "现存的对象" 放到新的环境中，而新环境要求的接口是现对象不能满足的。
何时使用：
- 系统需要使用现有的类，而此类的接口不符合系统的需要。
- 想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。
- 通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。）
如何解决： 继承或依赖（推荐）。
关键代码： 适配器继承或依赖已有的对象，实现想要的目标接口。
应用实例：
- 美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。
- JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。
- 在 LINUX 上运行 WINDOWS 程序。 4. JAVA 中的 jdbc。
优点：
- 可以让任何两个没有关联的类一起运行。
- 提高了类的复用。
- 增加了类的透明度。
- 灵活性好。
缺点：
- 过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。
- 由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。
使用场景： 有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。
注意事项： 适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。
桥接模式
桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。
介绍
意图： 将抽象部分与实现部分分离，使它们都可以独立的变化。
主要解决： 在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。
何时使用： 实现系统可能有多个角度分类，每一种角度都可能变化。
如何解决： 把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。
关键代码： 抽象类依赖实现类。
应用实例：
- 猪八戒从天蓬元帅转世投胎到猪，转世投胎的机制将尘世划分为两个等级，即：灵魂和肉体，前者相当于抽象化，后者相当于实现化。生灵通过功能的委派，调用肉体对象的功能，使得生灵可以动态地选择。
- 墙上的开关，可以看到的开关是抽象的，不用管里面具体怎么实现的。
优点：
- 抽象和实现的分离。
- 优秀的扩展能力。
- 实现细节对客户透明。
缺点： 桥接模式的引入会增加系统的理解与设计难度，由于聚合关联关系建立在抽象层，要求开发者针对抽象进行设计与编程。
使用场景：
- 如果一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。
- 对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，桥接模式尤为适用。
- 一个类存在两个独立变化的维度，且这两个维度都需要进行扩展。
注意事项： 对于两个独立变化的维度，使用桥接模式再适合不过了。
过滤器模式
过滤器模式（Filter Pattern）或标准模式（Criteria Pattern）是一种设计模式，这种模式允许开发人员使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来。这种类型的设计模式属于结构型模式，它结合多个标准来获得单一标准。
组合模式
组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。
这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。
介绍
意图： 将对象组合成树形结构以表示 "部分 - 整体" 的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
主要解决： 它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。
何时使用：
- 您想表示对象的部分 - 整体层次结构（树形结构）。
- 您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。
如何解决： 树枝和叶子实现统一接口，树枝内部组合该接口。
关键代码： 树枝内部组合该接口，并且含有内部属性 List，里面放 Component。
应用实例：
- 算术表达式包括操作数. 操作符和另一个操作数，其中，另一个操作符也可以是操作数. 操作符和另一个操作数。
- 在 JAVA AWT 和 SWING 中，对于 Button 和 Checkbox 是树叶，Container 是树枝。
优点：
- 高层模块调用简单。
- 节点自由增加。
缺点： 在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。
使用场景： 部分. 整体场景，如树形菜单，文件. 文件夹的管理。
注意事项： 定义时为具体类。
装饰器模式
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。
这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
介绍
意图： 动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。
主要解决： 一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。
何时使用： 在不想增加很多子类的情况下扩展类。
如何解决： 将具体功能职责划分，同时继承装饰者模式。
关键代码：
- Component 类充当抽象角色，不应该具体实现。
- 修饰类引用和继承 Component 类，具体扩展类重写父类方法。
应用实例：
- 孙悟空有 72 变，当他变成 "庙宇" 后，他的根本还是一只猴子，但是他又有了庙宇的功能。
- 不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。
优点： 装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
缺点： 多层装饰比较复杂。
使用场景：
- 扩展一个类的功能。
- 动态增加功能，动态撤销。
注意事项： 可代替继承。
外观模式
外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。
这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。
介绍
意图： 为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
主要解决： 降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。
何时使用：
- 客户端不需要知道系统内部的复杂联系，整个系统只需提供一个 "接待员" 即可。
- 定义系统的入口。
如何解决： 客户端不与系统耦合，外观类与系统耦合。
关键代码： 在客户端和复杂系统之间再加一层，这一层将调用顺序. 依赖关系等处理好。
应用实例：
- 去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。
- JAVA 的三层开发模式。
优点：
- 减少系统相互依赖。
- 提高灵活性。
- 提高了安全性。
缺点： 不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。
使用场景：
- 为复杂的模块或子系统提供外界访问的模块。
- 子系统相对独立。
- 预防低水平人员带来的风险。
注意事项： 在层次化结构中，可以使用外观模式定义系统中每一层的入口。
享元模式
享元模式（Flyweight Pattern）主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。
享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。我们将通过创建 5 个对象来画出 20 个分布于不同位置的圆来演示这种模式。由于只有 5 种可用的颜色，所以 color 属性被用来检查现有的 Circle 对象。
介绍
意图： 运用共享技术有效地支持大量细粒度的对象。
主要解决： 在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。
何时使用：
- 系统中有大量对象。
- 这些对象消耗大量内存。
- 这些对象的状态大部分可以外部化。
- 这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。
- 系统不依赖于这些对象身份，这些对象是不可分辨的。
如何解决： 用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象。
关键代码： 用 HashMap 存储这些对象。
应用实例：
- JAVA 中的 String，如果有则返回，如果没有则创建一个字符串保存在字符串缓存池里面。2. 数据库的数据池。
优点： 大大减少对象的创建，降低系统的内存，使效率提高。
缺点： 提高了系统的复杂度，需要分离出外部状态和内部状态，而且外部状态具有固有化的性质，不应该随着内部状态的变化而变化，否则会造成系统的混乱。
使用场景：
- 系统有大量相似对象。
- 需要缓冲池的场景。
注意事项：
- 注意划分外部状态和内部状态，否则可能会引起线程安全问题。
- 这些类必须有一个工厂对象加以控制。
代理模式
在代理模式（Proxy Pattern）中，一个类代表另一个类的功能。这种类型的设计模式属于结构型模式。
在代理模式中，我们创建具有现有对象的对象，以便向外界提供功能接口。
介绍
意图： 为其他对象提供一种代理以控制对这个对象的访问。
主要解决： 在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。
何时使用： 想在访问一个类时做一些控制。
如何解决： 增加中间层。
关键代码： 实现与被代理类组合。
应用实例：
- Windows 里面的快捷方式。
- 猪八戒去找高翠兰结果是孙悟空变的，可以这样理解：把高翠兰的外貌抽象出来，高翠兰本人和孙悟空都实现了这个接口，猪八戒访问高翠兰的时候看不出来这个是孙悟空，所以说孙悟空是高翠兰代理类。
- 买火车票不一定在火车站买，也可以去代售点。
- 一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。
- spring aop。
优点：
- 职责清晰。
- 高扩展性。
- 智能化。
缺点：
- 由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。
- 实现代理模式需要额外的工作，有些代理模式的实现非常复杂。
使用场景： 按职责来划分，通常有以下使用场景：
- 远程代理。
- 虚拟代理。
- Copy-on-Write 代理。
- 保护（Protect or Access）代理。
- Cache 代理。
- 防火墙（Firewall）代理。
- 同步化（Synchronization）代理。
- 智能引用（Smart Reference）代理。
注意事项：
- 和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。
- 和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。
数据映射模式
在了解数据映射模式之前，先了解下数据映射，它是在持久化数据存储层（通常是关系型数据库）和驻于内存的数据表现层之间进行双向数据传输的数据访问层。
数据映射模式的目的是让持久化数据存储层、驻于内存的数据表现层、以及数据映射本身三者相互独立、互不依赖。这个数据访问层由一个或多个映射器（或者数据访问对象）组成，用于实现数据传输。通用的数据访问层可以处理不同的实体类型，而专用的则处理一个或几个。
数据映射模式的核心在于它的数据模型遵循单一职责原则（Single Responsibility Principle）, 这也是和 Active Record 模式的不同之处。最典型的数据映射模式例子就是数据库 ORM 模型 （Object Relational Mapper）。
准确来说该模式是个架构模式。
依赖注入模式
依赖注入（Dependency Injection）是控制反转（Inversion of Control）的一种实现方式。
我们先来看看什么是控制反转。当调用者需要被调用者的协助时，在传统的程序设计过程中，通常由调用者来创建被调用者的实例，但在这里，创建被调用者的工作不再由调用者来完成，而是将被调用者的创建移到调用者的外部，从而反转被调用者的创建，消除了调用者对被调用者创建的控制，因此称为控制反转。
要实现控制反转，通常的解决方案是将创建被调用者实例的工作交由 IoC 容器来完成，然后在调用者中注入被调用者（通过构造器/方法注入实现），这样我们就实现了调用者与被调用者的解耦，该过程被称为依赖注入。
依赖注入不是目的，它是一系列工具和手段，最终的目的是帮助我们开发出松散耦合（loose coupled）、可维护、可测试的代码和程序。这条原则的做法是大家熟知的面向接口，或者说是面向抽象编程。
门面模式
门面模式（Facade）又称外观模式，用于为子系统中的一组接口提供一个一致的界面。门面模式定义了一个高层接口，这个接口使得子系统更加容易使用：引入门面角色之后，用户只需要直接与门面角色交互，用户与子系统之间的复杂关系由门面角色来实现，从而降低了系统的耦合度。
示例代码
Facade.php
<?php
namespace DesignPatterns\Structural\Facade;
/**
* 门面类
*/
class Facade
{
/**
* @var OsInterface
*/
protected $os;
/**
* @var BiosInterface
*/
protected $bios;
/**
* This is the perfect time to use a dependency injection container
* to create an instance of this class
*
* @param BiosInterface $bios
* @param OsInterface $os
*/
public function __construct(BiosInterface $bios, OsInterface $os)
{
$this->bios = $bios;
$this->os = $os;
}
/**
* turn on the system
*/
public function turnOn()
{
$this->bios->execute();
$this->bios->waitForKeyPress();
$this->bios->launch($this->os);
}
/**
* turn off the system
*/
public function turnOff()
{
$this->os->halt();
$this->bios->powerDown();
}
}
OsInterface.php
<?php
namespace DesignPatterns\Structural\Facade;
/**
* OsInterface接口
*/
interface OsInterface
{
/**
* halt the OS
*/
public function halt();
}
BiosInterface.php
<?php
namespace DesignPatterns\Structural\Facade;
/**
* BiosInterface接口
*/
interface BiosInterface
{
/**
* execute the BIOS
*/
public function execute();
/**
* wait for halt
*/
public function waitForKeyPress();
/**
* launches the OS
*
* @param OsInterface $os
*/
public function launch(OsInterface $os);
/**
* power down BIOS
*/
public function powerDown();
}
流接口模式
在软件工程中，流接口（Fluent Interface）是指实现一种面向对象的、能提高代码可读性的 API 的方法，其目的就是可以编写具有自然语言一样可读性的代码，我们对这种代码编写方式还有一个通俗的称呼 —— 方法链。
Laravel 中流接口模式有着广泛使用，比如查询构建器，邮件等等。
示例代码
Sql.php
<?php
namespace DesignPatterns\Structural\FluentInterface;
/**
* SQL 类
*/
class Sql
{
/**
* @var array
*/
protected $fields = array();
/**
* @var array
*/
protected $from = array();
/**
* @var array
*/
protected $where = array();
/**
* 添加 select 字段
*
* @param array $fields
*
* @return SQL
*/
public function select(array $fields = array())
{
$this->fields = $fields;
return $this;
}
/**
* 添加 FROM 子句
*
* @param string $table
* @param string $alias
*
* @return SQL
*/
public function from($table, $alias)
{
$this->from[] = $table . ' AS ' . $alias;
return $this;
}
/**
* 添加 WHERE 条件
*
* @param string $condition
*
* @return SQL
*/
public function where($condition)
{
$this->where[] = $condition;
return $this;
}
/**
* 生成查询语句
*
* @return string
*/
public function getQuery()
{
return 'SELECT ' . implode(',', $this->fields)
. ' FROM ' . implode(',', $this->from)
. ' WHERE ' . implode(' AND ', $this->where);
}
}
注册模式
注册模式（Registry）也叫做注册树模式，注册器模式。注册模式为应用中经常使用的对象创建一个中央存储器来存放这些对象 —— 通常通过一个只包含静态方法的抽象类来实现（或者通过单例模式）。
示例代码
Registry.php
<?php
namespace DesignPatterns\Structural\Registry;
/**
* class Registry
*/
abstract class Registry
{
const LOGGER = 'logger';
/**
* @var array
*/
protected static $storedValues = array();
/**
* sets a value
*
* @param string $key
* @param mixed $value
*
* @static
* @return void
*/
public static function set($key, $value)
{
self::$storedValues[$key] = $value;
}
/**
* gets a value from the registry
*
* @param string $key
*
* @static
* @return mixed
*/
public static function get($key)
{
return self::$storedValues[$key];
}
// typically there would be methods to check if a key has already been registered and so on ...
}
责任链模式
顾名思义，责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。
在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，依此类推。
介绍
意图： 避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
主要解决： 职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。
何时使用： 在处理消息的时候以过滤很多道。
如何解决： 拦截的类都实现统一接口。
关键代码： Handler 里面聚合它自己，在 HandlerRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。
应用实例：
- 红楼梦中的 "击鼓传花"。
- JS 中的事件冒泡。
- JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2 的拦截器，jsp servlet 的 Filter。
优点：
- 降低耦合度。它将请求的发送者和接收者解耦。
- 简化了对象。使得对象不需要知道链的结构。
- 增强给对象指派职责的灵活性。通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
- 增加新的请求处理类很方便。
缺点：
- 不能保证请求一定被接收。
- 系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用。
- 可能不容易观察运行时的特征，有碍于除错。
使用场景：
- 有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定。
- 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
- 可动态指定一组对象处理请求。
注意事项： 在 JAVA WEB 中遇到很多应用。
命令模式
命令模式（Command Pattern）是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。
介绍
意图： 将一个请求封装成一个对象，从而使您可以用不同的请求对客户进行参数化。
主要解决： 在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
何时使用： 在某些场合，比如要对行为进行 "记录、撤销 / 重做、事务" 等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将 "行为请求者" 与 "行为实现者" 解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
如何解决： 通过调用者调用接受者执行命令，顺序：调用者→接受者→命令。
关键代码： 定义三个角色：
- received 真正的命令执行对象
- Command
- invoker 使用命令对象的入口
应用实例： struts 1 中的 action 核心控制器 ActionServlet 只有一个，相当于 Invoker，而模型层的类会随着不同的应用有不同的模型类，相当于具体的 Command。
优点：
- 降低了系统耦合度。
- 新的命令可以很容易添加到系统中去。
缺点： 使用命令模式可能会导致某些系统有过多的具体命令类。
使用场景： 认为是命令的地方都可以使用命令模式，比如：
- GUI 中每一个按钮都是一条命令。
- 模拟 CMD。
注意事项： 系统需要支持命令的撤销 (Undo) 操作和恢复 (Redo) 操作，也可以考虑使用命令模式，见命令模式的扩展。
解释器模式
解释器模式（Interpreter Pattern）提供了评估语言的语法或表达式的方式，它属于行为型模式。这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被用在 SQL 解析、符号处理引擎等。
介绍
意图： 给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。
主要解决： 对于一些固定文法构建一个解释句子的解释器。
何时使用： 如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。
如何解决： 构建语法树，定义终结符与非终结符。
关键代码： 构建环境类，包含解释器之外的一些全局信息，一般是 HashMap。
应用实例： 编译器、运算表达式计算。
优点：
- 可扩展性比较好，灵活。
- 增加了新的解释表达式的方式。
- 易于实现简单文法。
缺点：
- 可利用场景比较少。
- 对于复杂的文法比较难维护。
- 解释器模式会引起类膨胀。
- 解释器模式采用递归调用方法。
使用场景：
- 可以将一个需要解释执行的语言中的句子表示为一个抽象语法树。
- 一些重复出现的问题可以用一种简单的语言来进行表达。
- 一个简单语法需要解释的场景。
注意事项： 可利用场景比较少，JAVA 中如果碰到可以用 expression4J 代替。
迭代器模式
迭代器模式（Iterator Pattern）是 Java 和 .Net 编程环境中非常常用的设计模式。这种模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。
迭代器模式属于行为型模式。
介绍
意图： 提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。
主要解决： 不同的方式来遍历整个整合对象。
何时使用： 遍历一个聚合对象。
如何解决： 把在元素之间游走的责任交给迭代器，而不是聚合对象。
关键代码： 定义接口：hasNext, next。
应用实例： JAVA 中的 iterator。
优点：
- 它支持以不同的方式遍历一个聚合对象。
- 迭代器简化了聚合类。
- 在同一个聚合上可以有多个遍历。
- 在迭代器模式中，增加新的聚合类和迭代器类都很方便，无须修改原有代码。
缺点： 由于迭代器模式将存储数据和遍历数据的职责分离，增加新的聚合类需要对应增加新的迭代器类，类的个数成对增加，这在一定程度上增加了系统的复杂性。
使用场景：
- 访问一个聚合对象的内容而无须暴露它的内部表示。
- 需要为聚合对象提供多种遍历方式。
- 为遍历不同的聚合结构提供一个统一的接口。
注意事项： 迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明地访问集合内部的数据。
中介者模式
中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。
介绍
意图： 用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
主要解决： 对象与对象之间存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。
何时使用： 多个类相互耦合，形成了网状结构。
如何解决： 将上述网状结构分离为星型结构。
关键代码： 对象 Colleague 之间的通信封装到一个类中单独处理。
应用实例：
- 中国加入 WTO 之前是各个国家相互贸易，结构复杂，现在是各个国家通过 WTO 来互相贸易。
- 机场调度系统。
- MVC 框架，其中 C（控制器）就是 M（模型）和 V（视图）的中介者。
优点：
- 降低了类的复杂度，将一对多转化成了一对一。
- 各个类之间的解耦。
- 符合迪米特原则。
缺点： 中介者会庞大，变得复杂难以维护。
使用场景：
- 系统中对象之间存在比较复杂的引用关系，导致它们之间的依赖关系结构混乱而且难以复用该对象。
- 想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。
注意事项： 不应当在职责混乱的时候使用。
备忘录模式
备忘录模式（Memento Pattern）保存一个对象的某个状态，以便在适当的时候恢复对象。备忘录模式属于行为型模式。
介绍
意图： 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
主要解决： 所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。
何时使用： 很多时候我们总是需要记录一个对象的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态，使得他有 " 后悔药" 可吃。
如何解决： 通过一个备忘录类专门存储对象状态。
关键代码： 客户不与备忘录类耦合，与备忘录管理类耦合。
应用实例：
- 后悔药。
- 打游戏时的存档。
- Windows 里的 ctri + z。
- IE 中的后退。
- 数据库的事务管理。
优点：
- 给用户提供了一种可以恢复状态的机制，可以使用户能够比较方便地回到某个历史的状态。
- 实现了信息的封装，使得用户不需要关心状态的保存细节。
缺点： 消耗资源。如果类的成员变量过多，势必会占用比较大的资源，而且每一次保存都会消耗一定的内存。
使用场景：
- 需要保存 / 恢复数据的相关状态场景。
- 提供一个可回滚的操作。
注意事项：
- 为了符合迪米特原则，还要增加一个管理备忘录的类。
- 为了节约内存，可使用原型模式 + 备忘录模式。
观察者模式
当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知它的依赖对象。观察者模式属于行为型模式。
介绍
意图： 定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
主要解决： 一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。
何时使用： 一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。
如何解决： 使用面向对象技术，可以将这种依赖关系弱化。
关键代码： 在抽象类里有一个 ArrayList 存放观察者们。
应用实例：
- 拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。
- 西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动作。
优点：
- 观察者和被观察者是抽象耦合的。
- 建立一套触发机制。
缺点：
- 如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。
- 如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。
- 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。
使用场景：
- 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。
- 一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。
- 一个对象必须通知其他对象，而并不知道这些对象是谁。
- 需要在系统中创建一个触发链，A 对象的行为将影响 B 对象，B 对象的行为将影响 C 对象……，可以使用观察者模式创建一种链式触发机制。
注意事项：
- JAVA 中已经有了对观察者模式的支持类。
- 避免循环引用。
- 如果顺序执行，某一观察者错误会导致系统卡壳，一般采用异步方式。
状态模式
在状态模式（State Pattern）中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。
在状态模式中，我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。
介绍
意图： 允许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。
主要解决： 对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。
何时使用： 代码中包含大量与对象状态有关的条件语句。
如何解决： 将各种具体的状态类抽象出来。
关键代码： 通常命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。而且，状态模式的实现类的方法，一般返回值，或者是改变实例变量的值。也就是说，状态模式一般和对象的状态有关。实现类的方法有不同的功能，覆盖接口中的方法。状态模式和命令模式一样，也可以用于消除 if...else 等条件选择语句。
应用实例：
- 打篮球的时候运动员可以有正常状态. 不正常状态和超常状态。
- 曾侯乙编钟中，'钟是抽象接口','钟 A'等是具体状态，'曾侯乙编钟'是具体环境（Context）。
优点：
- 封装了转换规则。
- 枚举可能的状态，在枚举状态之前需要确定状态种类。
- 将所有与某个状态有关的行为放到一个类中，并且可以方便地增加新的状态，只需要改变对象状态即可改变对象的行为。
- 允许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
- 可以让多个环境对象共享一个状态对象，从而减少系统中对象的个数。
缺点：
- 状态模式的使用必然会增加系统类和对象的个数。
- 状态模式的结构与实现都较为复杂，如果使用不当将导致程序结构和代码的混乱。
- 状态模式对 "开闭原则" 的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源代码，否则无法切换到新增状态，而且修改某个状态类的行为也需修改对应类的源代码。
使用场景：
- 行为随状态改变而改变的场景。
- 条件、分支语句的代替者。
注意事项： 在行为受状态约束的时候使用状态模式，而且状态不超过 5 个。
空对象模式
在空对象模式（Null Object Pattern）中，一个空对象取代 NULL 对象实例的检查。Null 对象不是检查空值，而是反应一个不做任何动作的关系。这样的 Null 对象也可以在数据不可用的时候提供默认的行为。
在空对象模式中，我们创建一个指定各种要执行的操作的抽象类和扩展该类的实体类，还创建一个未对该类做任何实现的空对象类，该空对象类将无缝地使用在需要检查空值的地方。
策略模式
在策略模式（Strategy Pattern）中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。
在策略模式中，我们创建表示各种策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。
介绍
意图： 定义一系列的算法, 把它们一个个封装起来, 并且使它们可相互替换。
主要解决： 在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。
何时使用： 一个系统有许多许多类，而区分它们的只是他们直接的行为。
如何解决： 将这些算法封装成一个一个的类，任意地替换。
关键代码： 实现同一个接口。
应用实例：
- 诸葛亮的锦囊妙计，每一个锦囊就是一个策略。
- 旅行的出游方式，选择骑自行车. 坐汽车，每一种旅行方式都是一个策略。
- JAVA AWT 中的 LayoutManager。
优点：
- 算法可以自由切换。
- 避免使用多重条件判断。
- 扩展性良好。
缺点：
- 策略类会增多。
- 所有策略类都需要对外暴露。
使用场景：
- 如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
- 一个系统需要动态地在几种算法中选择一种。
- 如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。
注意事项： 如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。
模板模式
在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式 / 模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。
介绍
意图： 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
主要解决： 一些方法通用，却在每一个子类都重新写了这一方法。
何时使用： 有一些通用的方法。
如何解决： 将这些通用算法抽象出来。
关键代码： 在抽象类实现，其他步骤在子类实现。
应用实例：
- 在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2. 西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。
- spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务. 获取 Session. 关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。
优点：
- 封装不变部分，扩展可变部分。
- 提取公共代码，便于维护。
- 行为由父类控制，子类实现。
缺点： 每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。
使用场景：
- 有多个子类共有的方法，且逻辑相同。
- 重要的、复杂的方法，可以考虑作为模板方法。
注意事项： 为防止恶意操作，一般模板方法都加上 final 关键词。
访问者模式
在访问者模式（Visitor Pattern）中，我们使用了一个访问者类，它改变了元素类的执行算法。通过这种方式，元素的执行算法可以随着访问者改变而改变。这种类型的设计模式属于行为型模式。根据模式，元素对象已接受访问者对象，这样访问者对象就可以处理元素对象上的操作。
介绍
意图： 主要将数据结构与数据操作分离。
主要解决： 稳定的数据结构和易变的操作耦合问题。
何时使用： 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作 "污染" 这些对象的类，使用访问者模式将这些封装到类中。
如何解决： 在被访问的类里面加一个对外提供接待访问者的接口。
关键代码： 在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。
应用实例： 您在朋友家做客，您是访问者，朋友接受您的访问，您通过朋友的描述，然后对朋友的描述做出一个判断，这就是访问者模式。
优点：
- 符合单一职责原则。
- 优秀的扩展性。
- 灵活性。
缺点：
- 具体元素对访问者公布细节，违反了迪米特原则。
- 具体元素变更比较困难。
- 违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
使用场景：
- 对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作。
- 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作 "污染" 这些对象的类，也不希望在增加新操作时修改这些类。
注意事项： 访问者可以对功能进行统一，可以做报表、UI、拦截器与过滤器。
规格模式
规格模式（Specification）可以认为是组合模式的一种扩展。有时项目中某些条件决定了业务逻辑，这些条件就可以抽离出来以某种关系（与、或、非）进行组合，从而灵活地对业务逻辑进行定制。另外，在查询、过滤等应用场合中，通过预定义多个条件，然后使用这些条件的组合来处理查询或过滤，而不是使用逻辑判断语句来处理，可以简化整个实现逻辑。
这里的每个条件就是一个规格，多个规格/条件通过串联的方式以某种逻辑关系形成一个组合式的规格。
访问者模式
我们去银行柜台办业务，一般情况下会开几个个人业务柜台的，你去其中任何一个柜台办理都是可以的。我们的访问者模式可以很好付诸在这个场景中：对于银行柜台来说，他们是不用变化的，就是说今天和明天提供个人业务的柜台是不需要有变化的。而我们作为访问者，今天来银行可能是取消费流水，明天来银行可能是去办理手机银行业务，这些是我们访问者的操作，一直是在变化的。
访问者模式就是表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
MVC模式
MVC 模式代表 Model-View-Controller（模型 - 视图 - 控制器） 模式。这种模式用于应用程序的分层开发。
- Model（模型） - 模型代表一个存取数据的对象或 JAVA POJO。它也可以带有逻辑，在数据变化时更新控制器。
- View（视图） - 视图代表模型包含的数据的可视化。
- Controller（控制器） - 控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。
业务代表模式
业务代表模式（Business Delegate Pattern）用于对表示层和业务层解耦。它基本上是用来减少通信或对表示层代码中的业务层代码的远程查询功能。在业务层中我们有以下实体。
- 客户端（Client） - 表示层代码可以是 JSP、servlet 或 UI java 代码。
- 业务代表（Business Delegate） - 一个为客户端实体提供的入口类，它提供了对业务服务方法的访问。
- 查询服务（LookUp Service） - 查找服务对象负责获取相关的业务实现，并提供业务对象对业务代表对象的访问。
- 业务服务（Business Service） - 业务服务接口。实现了该业务服务的实体类，提供了实际的业务实现逻辑。
组合实体模式
组合实体模式（Composite Entity Pattern）用在 EJB 持久化机制中。一个组合实体是一个 EJB 实体 bean，代表了对象的图解。当更新一个组合实体时，内部依赖对象 beans 会自动更新，因为它们是由 EJB 实体 bean 管理的。以下是组合实体 bean 的参与者。
- 组合实体（Composite Entity） - 它是主要的实体 bean。它可以是粗粒的，或者可以包含一个粗粒度对象，用于持续生命周期。
- 粗粒度对象（Coarse-Grained Object） - 该对象包含依赖对象。它有自己的生命周期，也能管理依赖对象的生命周期。
- 依赖对象（Dependent Object） - 依赖对象是一个持续生命周期依赖于粗粒度对象的对象。
- 策略（Strategies） - 策略表示如何实现组合实体。
数据访问对象模式
数据访问对象模式（Data Access Object Pattern）或 DAO 模式用于把低级的数据访问 API 或操作从高级的业务服务中分离出来。以下是数据访问对象模式的参与者。
- 数据访问对象接口（Data Access Object Interface） - 该接口定义了在一个模型对象上要执行的标准操作。
- 数据访问对象实体类（Data Access Object concrete class） - 该类实现了上述的接口。该类负责从数据源获取数据，数据源可以是数据库，也可以是 xml，或者是其他的存储机制。
- 模型对象 / 数值对象（Model Object/Value Object） - 该对象是简单的 POJO，包含了 get/set 方法来存储通过使用 DAO 类检索到的数据。
前端控制器模式
前端控制器模式（Front Controller Pattern）是用来提供一个集中的请求处理机制，所有的请求都将由一个单一的处理程序处理。该处理程序可以做认证 / 授权 / 记录日志，或者跟踪请求，然后把请求传给相应的处理程序。以下是这种设计模式的实体。
- 前端控制器（Front Controller） - 处理应用程序所有类型请求的单个处理程序，应用程序可以是基于 web 的应用程序，也可以是基于桌面的应用程序。
- 调度器（Dispatcher） - 前端控制器可能使用一个调度器对象来调度请求到相应的具体处理程序。
- 视图（View） - 视图是为请求而创建的对象。
拦截过滤器模式
拦截过滤器模式（Intercepting Filter Pattern）用于对应用程序的请求或响应做一些预处理 / 后处理。定义过滤器，并在把请求传给实际目标应用程序之前应用在请求上。过滤器可以做认证 / 授权 / 记录日志，或者跟踪请求，然后把请求传给相应的处理程序。以下是这种设计模式的实体。
- 过滤器（Filter） - 过滤器在请求处理程序执行请求之前或之后，执行某些任务。
- 过滤器链（Filter Chain） - 过滤器链带有多个过滤器，并在 Target 上按照定义的顺序执行这些过滤器。
- Target - Target 对象是请求处理程序。
- 过滤管理器（Filter Manager） - 过滤管理器管理过滤器和过滤器链。
- 客户端（Client） - Client 是向 Target 对象发送请求的对象。
服务定位器模式
服务定位器模式（Service Locator Pattern）用在我们想使用 JNDI 查询定位各种服务的时候。考虑到为某个服务查找 JNDI 的代价很高，服务定位器模式充分利用了缓存技术。在首次请求某个服务时，服务定位器在 JNDI 中查找服务，并缓存该服务对象。当再次请求相同的服务时，服务定位器会在它的缓存中查找，这样可以在很大程度上提高应用程序的性能。以下是这种设计模式的实体。
当系统中的组件需要调用某一服务来完成特定的任务时，通常最简单的做法是使用 new 关键字来创建该服务的实例，或者通过工厂模式来解耦该组件与服务的具体实现部分，以便通过配置信息等更为灵活的方式获得该服务的实例。然而，这些做法都有着各自的弊端：
- 在组件中直接维护对服务实例的引用，会造成组件与服务之间的关联依赖，当需要替换服务的具体实现时，不得不修改组件中调用服务的部分并重新编译解决方案；即使采用工厂模式来根据配置信息动态地获得服务的实例，也无法针对不同的服务类型向组件提供一个管理服务实例的中心位置；
- 由于组件与服务之间的这种关联依赖，使得项目的开发过程受到约束。在实际项目中，开发过程往往是并行的，但又不是完全同步的，比如组件的开发跟其所需要的服务的开发同时进行，但很有可能当组件需要调用服务时，服务却还没完成开发和单体测试。遇到这种问题时，通常会将组件调用服务的部分暂时空缺，待到服务完成开发和单体测试之后，将其集成到组件的代码中。但这种做法不仅费时，而且增大了出错的风险；
- 针对组件的单体测试变得复杂。每当对组件进行单体测试时，不得不为其配置并运行所需要的服务，而无法使用Service Stub来解决组件与服务之间的依赖；
- 在组件中可能存在多个地方需要引用服务的实例，在这种情况下，直接创建服务实例的代码会散布到整个程序中，造成一段程序存在多个副本，大大增加维护和排错成本；
- 当组件需要调用多个服务时，不同服务初始化各自实例的方式又可能存在差异。开发人员不得不了解所有服务初始化的API，以便在程序中能够正确地使用这些服务；
- 某些服务的初始化过程需要耗费大量资源，因此多次重复地初始化服务会大大增加系统的资源占用和性能损耗。程序中需要有一个管理服务初始化过程的机制，在统一初始化接口的同时，还需要为程序提供部分缓存功能。
要解决以上问题，我们可以在应用程序中引入服务定位器（Service Locator）模式。
服务定位器（Service Locator）模式是一种企业级应用程序体系结构模式，它能够为应用程序中服务的创建和初始化提供一个中心位置，并解决了上文中所提到的各种设计和开发问题。
服务定位器模式和依赖注入模式都是控制反转（IoC）模式的实现。我们在服务定位器中注册给定接口的服务实例，然后通过接口获取服务并在应用代码中使用而不需要关心其具体实现。我们可以在启动时配置并注入服务提供者。
如果你了解 Laravel 框架，你对这一流程会很熟悉，没错，这就是 Laravel 框架的核心机制，我们在服务提供者中绑定接口及其实现，将服务实例注册到服务容器中，然后在使用时可以通过依赖注入或者通过服务接口/别名获取服务实例的方式调用服务。
- 服务（Service） - 实际处理请求的服务。对这种服务的引用可以在 JNDI 服务器中查找到。
- Context / 初始的 Context - JNDI Context 带有对要查找的服务的引用。
- 服务定位器（Service Locator） - 服务定位器是通过 JNDI 查找和缓存服务来获取服务的单点接触。
- 缓存（Cache） - 缓存存储服务的引用，以便复用它们。
- 客户端（Client） - Client 是通过 ServiceLocator 调用服务的对象。
传输对象模式
传输对象模式（Transfer Object Pattern）用于从客户端向服务器一次性传递带有多个属性的数据。传输对象也被称为数值对象。传输对象是一个具有 getter/setter 方法的简单的 POJO 类，它是可序列化的，所以它可以通过网络传输。它没有任何的行为。服务器端的业务类通常从数据库读取数据，然后填充 POJO，并把它发送到客户端或按值传递它。对于客户端，传输对象是只读的。客户端可以创建自己的传输对象，并把它传递给服务器，以便一次性更新数据库中的数值。以下是这种设计模式的实体。
- 业务对象（Business Object） - 为传输对象填充数据的业务服务。
- 传输对象（Transfer Object） - 简单的 POJO，只有设置 / 获取属性的方法。
- 客户端（Client） - 客户端可以发送请求或者发送传输对象到业务对象。
委托模式
委托是对一个类的功能进行扩展和复用的方法。它的做法是：写一个附加的类提供附加的功能，并使用原来的类的实例提供原有的功能。 假设我们有一个 TeamLead 类，将其既定任务委托给一个关联辅助对象 JuniorDeveloper 来完成：本来 TeamLead 处理 writeCode 方法，Usage 调用 TeamLead 的该方法，但现在 TeamLead 将 writeCode 的实现委托给 JuniorDeveloper 的 writeBadCode 来实现，但 Usage 并没有感知在执行 writeBadCode 方法。
示例代码
Usage.php
<?php
namespace DesignPatterns\More\Delegation;
// 初始化 TeamLead 并委托辅助者 JuniorDeveloper
$teamLead = new TeamLead(new JuniorDeveloper());
// TeamLead 将编写代码的任务委托给 JuniorDeveloper
echo $teamLead->writeCode();
TeamLead.php
<?php
namespace DesignPatterns\More\Delegation;
/**
* TeamLead类
* @package DesignPatterns\Delegation
* `TeamLead` 类将工作委托给 `JuniorDeveloper`
*/
class TeamLead
{
/** @var JuniorDeveloper */
protected $slave;
/**
* 在构造函数中注入初级开发者JuniorDeveloper
* @param JuniorDeveloper $junior
*/
public function __construct(JuniorDeveloper $junior)
{
$this->slave = $junior;
}
/**
* TeamLead 喝咖啡, JuniorDeveloper 工作
* @return mixed
*/
public function writeCode()
{
return $this->slave->writeBadCode();
}
}
JuniorDeveloper.php
<?php
namespace DesignPatterns\More\Delegation;
/**
* JuniorDeveloper 类
* @package DesignPatterns\Delegation
*/
class JuniorDeveloper
{
public function writeBadCode()
{
return "Some junior developer generated code...";
}
}
资源库模式
Repository 是一个独立的层，介于领域层与数据映射层（数据访问层）之间。它的存在让领域层感觉不到数据访问层的存在，它提供一个类似集合的接口提供给领域层进行领域对象的访问。Repository 是仓库管理员，领域层需要什么东西只需告诉仓库管理员，由仓库管理员把东西拿给它，并不需要知道东西实际放在哪。
Repository 模式是架构模式，在设计架构时，才有参考价值。应用 Repository 模式所带来的好处，远高于实现这个模式所增加的代码。只要项目分层，都应当使用这个模式。
示例代码
Post.php
<?php
namespace DesignPatterns\More\Repository;
/**
* Post 类
* @package DesignPatterns\Repository
*/
class Post
{
/**
* @var int
*/
private $id;
/**
* @var string
*/
private $title;
/**
* @var string
*/
private $text;
/**
* @var string
*/
private $author;
/**
* @var \DateTime
*/
private $created;
/**
* @param int $id
*/
public function setId($id)
{
$this->id = $id;
}
/**
* @return int
*/
public function getId()
{
return $this->id;
}
/**
* @param string $author
*/
public function setAuthor($author)
{
$this->author = $author;
}
/**
* @return string
*/
public function getAuthor()
{
return $this->author;
}
/**
* @param \DateTime $created
*/
public function setCreated($created)
{
$this->created = $created;
}
/**
* @return \DateTime
*/
public function getCreated()
{
return $this->created;
}
/**
* @param string $text
*/
public function setText($text)
{
$this->text = $text;
}
/**
* @return string
*/
public function getText()
{
return $this->text;
}
/**
* @param string $title
*/
public function setTitle($title)
{
$this->title = $title;
}
/**
* @return string
*/
public function getTitle()
{
return $this->title;
}
}
PostRepository.php
<?php
namespace DesignPatterns\More\Repository;
use DesignPatterns\More\Repository\Storage;
/**
* Post 对应的 Repository
* 该类介于数据实体层(Post) 和访问对象层(Storage)之间
*
* Repository 封装了持久化对象到数据存储器以及在展示层显示面向对象的视图操作
*
* Repository 还实现了领域层和数据映射层的分离和单向依赖
*
* PostRepository 类
* @package DesignPatterns\Repository
*/
class PostRepository
{
private $persistence;
public function __construct(Storage $persistence)
{
$this->persistence = $persistence;
}
/**
* 通过指定id返回Post对象
*
* @param int $id
* @return Post|null
*/
public function getById($id)
{
$arrayData = $this->persistence->retrieve($id);
if (is_null($arrayData)) {
return null;
}
$post = new Post();
$post->setId($arrayData['id']);
$post->setAuthor($arrayData['author']);
$post->setCreated($arrayData['created']);
$post->setText($arrayData['text']);
$post->setTitle($arrayData['title']);
return $post;
}
/**
* 保存指定对象并返回
*
* @param Post $post
* @return Post
*/
public function save(Post $post)
{
$id = $this->persistence->persist(array(
'author' => $post->getAuthor(),
'created' => $post->getCreated(),
'text' => $post->getText(),
'title' => $post->getTitle()
));
$post->setId($id);
return $post;
}
/**
* 删除指定的 Post 对象
*
* @param Post $post
* @return bool
*/
public function delete(Post $post)
{
return $this->persistence->delete($post->getId());
}
}
Storage.php
<?php
namespace DesignPatterns\More\Repository;
/**
* Storage接口
*
* 该接口定义了访问数据存储器的方法
* 具体的实现可以是多样化的，比如内存、关系型数据库、NoSQL数据库等等
*
* @package DesignPatterns\Repository
*/
interface Storage
{
/**
* 持久化数据方法
* 返回新创建的对象ID
*
* @param array() $data
* @return int
*/
public function persist($data);
/**
* 通过指定id返回数据
* 如果为空返回null
*
* @param int $id
* @return array|null
*/
public function retrieve($id);
/**
* 通过指定id删除数据
* 如果数据不存在返回false，否则如果删除成功返回true
*
* @param int $id
* @return bool
*/
public function delete($id);
}
MemoryStorage.php
<?php
namespace DesignPatterns\More\Repository;
use DesignPatterns\More\Repository\Storage;
/**
* MemoryStorage类
* @package DesignPatterns\Repository
*/
class MemoryStorage implements Storage
{
private $data;
private $lastId;
public function __construct()
{
$this->data = array();
$this->lastId = 0;
}
/**
* {@inheritdoc}
*/
public function persist($data)
{
$this->data[++$this->lastId] = $data;
return $this->lastId;
}
/**
* {@inheritdoc}
*/
public function retrieve($id)
{
return isset($this->data[$id]) ? $this->data[$id] : null;
}
/**
* {@inheritdoc}
*/
public function delete($id)
{
if (!isset($this->data[$id])) {
return false;
}
$this->data[$id] = null;
unset($this->data[$id]);
return true;
}
}