超全的设计模式简介（45种）

该文建议配合 design-patterns-for-humans 中文版 一块儿看。

推荐阅读

• 超全的设计模式简介（45种）
• design-patterns-for-humans 中文版（github 仓库永久更新）
• MongoDB 资源、库、工具、应用程序精选列表中文版
• 有哪些不为人知，可是颇有意思的网站？
• 一份攻城狮笔记
• 天天搜集 Github 上优秀的项目
• 一些有趣的民间故事
• 超好用的谷歌浏览器、Sublime Text、Phpstorm、油猴插件合集

设计模式（Design pattern）表明了最佳的实践，一般被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程当中面临的通常问题的解决方案。这些解决方案是众多软件开发人员通过至关长的一段时间的试验和错误总结出来的。
设计模式是一套被反复使用的、多数人知晓的、通过分类编目的、代码设计经验的总结。使用设计模式是为了重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石同样。项目中合理地运用设计模式能够完美地解决不少问题，每种模式在现实中都有相应的原理来与之对应，每种模式都描述了一个在咱们周围不断重复发生的问题，以及该问题的核心解决方案，这也是设计模式能被普遍应用的缘由。

设计模式的类型

共有 23 种设计模式。这些模式能够分为三大类：

• 建立型模式（Creational Patterns）- 这些设计模式提供了一种在建立对象的同时隐藏建立逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例须要建立哪些对象时更加灵活。

  • 工厂模式（Factory Pattern）
  • 抽象工厂模式（Abstract Factory Pattern）
  • 单例模式（Singleton Pattern）
  • 建造者模式（Builder Pattern）
  • 原型模式（Prototype Pattern）
  • 对象池模式 *（Pool）
  • 多例模式 *（Multiton）
  • 静态工厂模式 *（Static Factory）

• 结构型模式（Structural Patterns）- 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象得到新功能的方式。

  • 适配器模式（Adapter Pattern）
  • 桥接模式（Bridge Pattern）
  • 过滤器模式（Filter、Criteria Pattern）
  • 组合模式（Composite Pattern）
  • 装饰器模式（Decorator Pattern）
  • 外观模式（Facade Pattern）
  • 享元模式（Flyweight Pattern）
  • 代理模式（Proxy Pattern）
  • 数据映射模式 *（Data Mapper）
  • 依赖注入模式 *（Dependency Injection）
  • 门面模式 *（Facade）
  • 流接口模式 *（Fluent Interface）
  • 注册模式 *（Registry）

• 行为型模式（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 鉴定的。

  • MVC模式（MVC Pattern）
  • 业务表明模式（Business Delegate Pattern）
  • 组合实体模式（Composite Entity Pattern）
  • 数据访问对象模式（Data Access Object Pattern）
  • 前端控制器模式（Front Controller Pattern）
  • 拦截过滤器模式（Intercepting Filter Pattern）
  • 服务定位器模式（Service Locator Pattern）
  • 传输对象模式（Transfer Object Pattern）
  • 委托模式 *（Delegation）
  • 资源库模式 *（Repository）

下面用一个图片来总体描述一下设计模式之间的关系：

设计模式的六大原则

一、开闭原则（Open Close Principle）

开闭原则的意思是：对扩展开放，对修改关闭。在程序须要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，咱们须要使用接口和抽象类，后面的具体设计中咱们会提到这点。

二、里氏代换原则（Liskov Substitution Principle）

里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类能够出现的地方，子类必定能够出现。LSP 是继承复用的基石，只有当派生类能够替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也可以在基类的基础上增长新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，因此里氏代换原则是对实现抽象化的具体步骤的规范。

三、依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

四、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另一个意思是：下降类之间的耦合度。因而可知，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调下降依赖，下降耦合。

五、迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽可能少地与其余实体之间发生相互做用，使得系统功能模块相对独立。

六、合成复用原则（Composite Reuse Principle）

合成复用原则是指：尽可能使用合成 / 聚合的方式，而不是使用继承。

工厂模式

工厂模式（Factory Pattern）最经常使用的设计模式之一。这种类型的设计模式属于建立型模式，它提供了一种建立对象的最佳方式。
在工厂模式中，咱们在建立对象时不会对客户端暴露建立逻辑，而且是经过使用一个共同的接口来指向新建立的对象。

介绍

意图： 定义一个建立对象的接口，让其子类本身决定实例化哪个工厂类，工厂模式使其建立过程延迟到子类进行。

主要解决： 主要解决接口选择的问题。

什么时候使用： 咱们明确地计划不一样条件下建立不一样实例时。

如何解决： 让其子类实现工厂接口，返回的也是一个抽象的产品。

关键代码： 建立过程在其子类执行。

应用实例：

1. 您须要一辆汽车，能够直接从工厂里面提货，而不用去管这辆汽车是怎么作出来的，以及这个汽车里面的具体实现。
2. Hibernate 换数据库只需换方言和驱动就能够。

优势：

1. 一个调用者想建立一个对象，只要知道其名称就能够了。
2. 扩展性高，若是想增长一个产品，只要扩展一个工厂类就能够。
3. 屏蔽产品的具体实现，调用者只关心产品的接口。

缺点： 每次增长一个产品时，都须要增长一个具体类和对象实现工厂，使得系统中类的个数成倍增长，在必定程度上增长了系统的复杂度，同时也增长了系统具体类的依赖。这并非什么好事。

使用场景：

1. 日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户能够选择记录日志到什么地方。
2. 数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。
3. 设计一个链接服务器的框架，须要三个协议，"POP3"、"IMAP"、"HTTP"，能够把这三个做为产品类，共同实现一个接口。

注意事项： 做为一种建立类模式，在任何须要生成复杂对象的地方，均可以使用工厂方法模式。有一点须要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只须要经过 new 就能够完成建立的对象，无需使用工厂模式。若是使用工厂模式，就须要引入一个工厂类，会增长系统的复杂度。

抽象工厂模式

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂建立其余工厂。该超级工厂又称为其余工厂的工厂。这种类型的设计模式属于建立型模式，它提供了一种建立对象的最佳方式。
在抽象工厂模式中，接口是负责建立一个相关对象的工厂，不须要显式指定它们的类。每一个生成的工厂都能按照工厂模式提供对象。

介绍

意图： 提供一个建立一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

主要解决： 主要解决接口选择的问题。

什么时候使用： 系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。

如何解决： 在一个产品族里面，定义多个产品。

关键代码： 在一个工厂里聚合多个同类产品。

应用实例： 工做了，为了参加一些聚会，确定有两套或多套衣服吧，好比说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来讲，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种状况（现实中是不存在的，要否则，无法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也天然要从这个衣柜中取出了。用 OO 的思想去理解，全部的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另外一个抽象产品）。

优势： 当一个产品族中的多个对象被设计成一块儿工做时，它能保证客户端始终只使用同一个产品族中的对象。

缺点： 产品族扩展很是困难，要增长一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。

使用场景：

1. QQ 换皮肤，一整套一块儿换。
2. 生成不一样操做系统的程序。

注意事项： 产品族难扩展，产品等级易扩展。

单例模式

单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于建立型模式，它提供了一种建立对象的最佳方式。
这种模式涉及到一个单一的类，该类负责建立本身的对象，同时确保只有单个对象被建立。这个类提供了一种访问其惟一的对象的方式，能够直接访问，不须要实例化该类的对象。

注意：

• 一、单例类只能有一个实例。
• 二、单例类必须本身建立本身的惟一实例。
• 三、单例类必须给全部其余对象提供这一实例。

介绍

意图： 保证一个类仅有一个实例，并提供一个访问它的全局访问点。

主要解决： 一个全局使用的类频繁地建立与销毁。

什么时候使用： 当您想控制实例数目，节省系统资源的时候。

如何解决： 判断系统是否已经有这个单例，若是有则返回，若是没有则建立。

关键代码： 构造函数是私有的。

应用实例：

1. 一个班级只有一个班主任。
2. Windows 是多进程多线程的，在操做一个文件的时候，就不可避免地出现多个进程或线程同时操做一个文件的现象，因此全部文件的处理必须经过惟一的实例来进行。
3. 一些设备管理器经常设计为单例模式，好比一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。

优势：

1. 在内存里只有一个实例，减小了内存的开销，尤为是频繁的建立和销毁实例（好比管理学院首页页面缓存）。
2. 避免对资源的多重占用（好比写文件操做）。

缺点： 没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。

使用场景：

1. 要求生产惟一序列号。
2. WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。
3. 建立的一个对象须要消耗的资源过多，好比 I/O 与数据库的链接等。

注意事项：getInstance() 方法中须要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入形成 instance 被屡次实例化。

建造者模式

建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于建立型模式，它提供了一种建立对象的最佳方式。
一个 Builder 类会一步一步构造最终的对象。该 Builder 类是独立于其余对象的。

介绍

意图： 将一个复杂的构建与其表示相分离，使得一样的构建过程能够建立不一样的表示。

主要解决： 主要解决在软件系统中，有时候面临着 "一个复杂对象" 的建立工做，其一般由各个部分的子对象用必定的算法构成；因为需求的变化，这个复杂对象的各个部分常常面临着剧烈的变化，可是将它们组合在一块儿的算法却相对稳定。

什么时候使用： 一些基本部件不会变，而其组合常常变化的时候。

如何解决： 将变与不变分离开。

关键代码： 建造者：建立和提供实例，导演：管理建造出来的实例的依赖关系。

应用实例：

1. 去肯德基，汉堡、可乐、薯条、炸鸡翅等是不变的，而其组合是常常变化的，生成出所谓的 "套餐"。
2. JAVA 中的 StringBuilder。

优势：

1. 建造者独立，易扩展。
2. 便于控制细节风险。

缺点：

1. 产品必须有共同点，范围有限制。
2. 如内部变化复杂，会有不少的建造类。

使用场景：

1. 须要生成的对象具备复杂的内部结构。
2. 须要生成的对象内部属性自己相互依赖。

注意事项： 与工厂模式的区别是：建造者模式更加关注与零件装配的顺序。

原型模式

原型模式（Prototype Pattern）是用于建立重复的对象，同时又能保证性能。这种类型的设计模式属于建立型模式，它提供了一种建立对象的最佳方式。
这种模式是实现了一个原型接口，该接口用于建立当前对象的克隆。当直接建立对象的代价比较大时，则采用这种模式。例如，一个对象须要在一个高代价的数据库操做以后被建立。咱们能够缓存该对象，在下一个请求时返回它的克隆，在须要的时候更新数据库，以此来减小数据库调用。

介绍

意图： 用原型实例指定建立对象的种类，而且经过拷贝这些原型建立新的对象。

主要解决： 在运行期创建和删除原型。

什么时候使用：

1. 当一个系统应该独立于它的产品建立，构成和表示时。
2. 当要实例化的类是在运行时刻指定时，例如，经过动态装载。
3. 为了不建立一个与产品类层次平行的工厂类层次时。
4. 当一个类的实例只能有几个不一样状态组合中的一种时。创建相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。

如何解决： 利用已有的一个原型对象，快速地生成和原型对象同样的实例。

关键代码：

1. 实现克隆操做，在 JAVA 继承 Cloneable，重写 clone()，在 .NET 中能够使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或经过序列化的方式来实现深拷贝。
2. 原型模式一样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它一样要求这些 "易变类" 拥有稳定的接口。

应用实例：

1. 细胞分裂。
2. JAVA 中的 Object clone() 方法。

优势：

1. 性能提升。
2. 逃避构造函数的约束。

缺点：

1. 配备克隆方法须要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不必定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。
2. 必须实现 Cloneable 接口。

使用场景：

1. 资源优化场景。
2. 类初始化须要消化很是多的资源，这个资源包括数据. 硬件资源等。
3. 性能和安全要求的场景。
4. 经过 new 产生一个对象须要很是繁琐的数据准备或访问权限，则能够使用原型模式。
5. 一个对象多个修改者的场景。
6. 一个对象须要提供给其余对象访问，并且各个调用者可能都须要修改其值时，能够考虑使用原型模式拷贝多个对象供调用者使用。
7. 在实际项目中，原型模式不多单独出现，通常是和工厂方法模式一块儿出现，经过 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）是做为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。
这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是做为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就能够经过笔记原本读取内存卡。

介绍

意图： 将一个类的接口转换成客户但愿的另一个接口。适配器模式使得本来因为接口不兼容而不能一块儿工做的那些类能够一块儿工做。

主要解决： 主要解决在软件系统中，经常要将一些 "现存的对象" 放到新的环境中，而新环境要求的接口是现对象不能知足的。

什么时候使用：

1. 系统须要使用现有的类，而此类的接口不符合系统的须要。
2. 想要创建一个能够重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在未来引进的类一块儿工做，这些源类不必定有一致的接口。
3. 经过接口转换，将一个类插入另外一个类系中。（好比老虎和飞禽，如今多了一个飞虎，在不增长实体的需求下，增长一个适配器，在里面包容一个虎对象，实现飞的接口。）

如何解决： 继承或依赖（推荐）。

关键代码： 适配器继承或依赖已有的对象，实现想要的目标接口。

应用实例：

1. 美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。
2. JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将之前系统的 Enumeration 接口转化为 Iterator 接口，这时就须要适配器模式。
3. 在 LINUX 上运行 WINDOWS 程序。 4. JAVA 中的 jdbc。

优势：

1. 可让任何两个没有关联的类一块儿运行。
2. 提升了类的复用。
3. 增长了类的透明度。
4. 灵活性好。

缺点：

1. 过多地使用适配器，会让系统很是零乱，不易总体进行把握。好比，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统若是太多出现这种状况，无异于一场灾难。所以若是不是颇有必要，能够不使用适配器，而是直接对系统进行重构。
2. 因为 JAVA 至多继承一个类，因此至多只能适配一个适配者类，并且目标类必须是抽象类。

使用场景： 有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。

注意事项： 适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。

桥接模式

桥接（Bridge）是用于把抽象化与实现化解耦，使得两者能够独立变化。这种类型的设计模式属于结构型模式，它经过提供抽象化和实现化之间的桥接结构，来实现两者的解耦。
这种模式涉及到一个做为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。

介绍

意图： 将抽象部分与实现部分分离，使它们均可以独立的变化。

主要解决： 在有多种可能会变化的状况下，用继承会形成类爆炸问题，扩展起来不灵活。

什么时候使用： 实现系统可能有多个角度分类，每一种角度均可能变化。

如何解决： 把这种多角度分类分离出来，让它们独立变化，减小它们之间耦合。

关键代码： 抽象类依赖实现类。

应用实例：

1. 猪八戒从天蓬元帅转世投胎到猪，转世投胎的机制将尘世划分为两个等级，即：灵魂和肉体，前者至关于抽象化，后者至关于实现化。生灵经过功能的委派，调用肉体对象的功能，使得生灵能够动态地选择。
2. 墙上的开关，能够看到的开关是抽象的，不用管里面具体怎么实现的。

优势：

1. 抽象和实现的分离。
2. 优秀的扩展能力。
3. 实现细节对客户透明。

缺点： 桥接模式的引入会增长系统的理解与设计难度，因为聚合关联关系创建在抽象层，要求开发者针对抽象进行设计与编程。

使用场景：

1. 若是一个系统须要在构件的抽象化角色和具体化角色之间增长更多的灵活性，避免在两个层次之间创建静态的继承联系，经过桥接模式能够使它们在抽象层创建一个关联关系。
2. 对于那些不但愿使用继承或由于多层次继承致使系统类的个数急剧增长的系统，桥接模式尤其适用。
3. 一个类存在两个独立变化的维度，且这两个维度都须要进行扩展。

注意事项： 对于两个独立变化的维度，使用桥接模式再适合不过了。

过滤器模式

过滤器模式（Filter Pattern）或标准模式（Criteria Pattern）是一种设计模式，这种模式容许开发人员使用不一样的标准来过滤一组对象，经过逻辑运算以解耦的方式把它们链接起来。这种类型的设计模式属于结构型模式，它结合多个标准来得到单一标准。

组合模式

组合模式（Composite Pattern），又叫部分总体模式，是用于把一组类似的对象看成一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及总体层次。这种类型的设计模式属于结构型模式，它建立了对象组的树形结构。
这种模式建立了一个包含本身对象组的类。该类提供了修改相同对象组的方式。

介绍

意图： 将对象组合成树形结构以表示 "部分 - 总体" 的层次结构。组合模式使得用户对单个对象和组合对象的使用具备一致性。

主要解决： 它在咱们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序能够向处理简单元素同样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。

什么时候使用：

1. 您想表示对象的部分 - 总体层次结构（树形结构）。
2. 您但愿用户忽略组合对象与单个对象的不一样，用户将统一地使用组合结构中的全部对象。

如何解决： 树枝和叶子实现统一接口，树枝内部组合该接口。

关键代码： 树枝内部组合该接口，而且含有内部属性 List，里面放 Component。

应用实例：

1. 算术表达式包括操做数. 操做符和另外一个操做数，其中，另外一个操做符也能够是操做数. 操做符和另外一个操做数。
2. 在 JAVA AWT 和 SWING 中，对于 Button 和 Checkbox 是树叶，Container 是树枝。

优势：

1. 高层模块调用简单。
2. 节点自由增长。

缺点： 在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。

使用场景： 部分. 总体场景，如树形菜单，文件. 文件夹的管理。

注意事项： 定义时为具体类。

装饰器模式

装饰器模式（Decorator Pattern）容许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是做为现有的类的一个包装。
这种模式建立了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。

介绍

意图： 动态地给一个对象添加一些额外的职责。就增长功能来讲，装饰器模式相比生成子类更为灵活。

主要解决： 通常的，咱们为了扩展一个类常用继承方式实现，因为继承为类引入静态特征，而且随着扩展功能的增多，子类会很膨胀。

什么时候使用： 在不想增长不少子类的状况下扩展类。

如何解决： 将具体功能职责划分，同时继承装饰者模式。

关键代码：

1. Component 类充当抽象角色，不该该具体实现。
2. 修饰类引用和继承 Component 类，具体扩展类重写父类方法。

应用实例：

1. 孙悟空有 72 变，当他变成 "庙宇" 后，他的根本仍是一只猴子，可是他又有了庙宇的功能。
2. 不论一幅画有没有画框均可以挂在墙上，可是一般都是有画框的，而且其实是画框被挂在墙上。在挂在墙上以前，画能够被蒙上玻璃，装到框子里；这时画、玻璃和画框造成了一个物体。

优势： 装饰类和被装饰类能够独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式能够动态扩展一个实现类的功能。

缺点： 多层装饰比较复杂。

使用场景：

1. 扩展一个类的功能。
2. 动态增长功能，动态撤销。

注意事项： 可代替继承。

外观模式

外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端能够访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。
这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

介绍

意图： 为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

主要解决： 下降访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。

什么时候使用：

1. 客户端不须要知道系统内部的复杂联系，整个系统只需提供一个 "接待员" 便可。
2. 定义系统的入口。

如何解决： 客户端不与系统耦合，外观类与系统耦合。

关键代码： 在客户端和复杂系统之间再加一层，这一层将调用顺序. 依赖关系等处理好。

应用实例：

1. 去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家眷以为很复杂，若是有提供接待人员，只让接待人员来处理，就很方便。
2. JAVA 的三层开发模式。

优势：

1. 减小系统相互依赖。
2. 提升灵活性。
3. 提升了安全性。

缺点： 不符合开闭原则，若是要改东西很麻烦，继承重写都不合适。

使用场景：

1. 为复杂的模块或子系统提供外界访问的模块。
2. 子系统相对独立。
3. 预防低水平人员带来的风险。

注意事项： 在层次化结构中，能够使用外观模式定义系统中每一层的入口。

享元模式

享元模式（Flyweight Pattern）主要用于减小建立对象的数量，以减小内存占用和提升性能。这种类型的设计模式属于结构型模式，它提供了减小对象数量从而改善应用所需的对象结构的方式。
享元模式尝试重用现有的同类对象，若是未找到匹配的对象，则建立新对象。咱们将经过建立 5 个对象来画出 20 个分布于不一样位置的圆来演示这种模式。因为只有 5 种可用的颜色，因此 color 属性被用来检查现有的 Circle 对象。

介绍

意图： 运用共享技术有效地支持大量细粒度的对象。

主要解决： 在有大量对象时，有可能会形成内存溢出，咱们把其中共同的部分抽象出来，若是有相同的业务请求，直接返回在内存中已有的对象，避免从新建立。

什么时候使用：

1. 系统中有大量对象。
2. 这些对象消耗大量内存。
3. 这些对象的状态大部分能够外部化。
4. 这些对象能够按照内蕴状态分为不少组，当把外蕴对象从对象中剔除出来时，每一组对象均可以用一个对象来代替。
5. 系统不依赖于这些对象身份，这些对象是不可分辨的。

如何解决： 用惟一标识码判断，若是在内存中有，则返回这个惟一标识码所标识的对象。

关键代码： 用 HashMap 存储这些对象。

应用实例：

1. JAVA 中的 String，若是有则返回，若是没有则建立一个字符串保存在字符串缓存池里面。2. 数据库的数据池。

优势： 大大减小对象的建立，下降系统的内存，使效率提升。

缺点： 提升了系统的复杂度，须要分离出外部状态和内部状态，并且外部状态具备固有化的性质，不该该随着内部状态的变化而变化，不然会形成系统的混乱。

使用场景：

1. 系统有大量类似对象。
2. 须要缓冲池的场景。

注意事项：

1. 注意划分外部状态和内部状态，不然可能会引发线程安全问题。
2. 这些类必须有一个工厂对象加以控制。

代理模式

在代理模式（Proxy Pattern）中，一个类表明另外一个类的功能。这种类型的设计模式属于结构型模式。
在代理模式中，咱们建立具备现有对象的对象，以便向外界提供功能接口。

介绍

意图： 为其余对象提供一种代理以控制对这个对象的访问。

主要解决： 在直接访问对象时带来的问题，好比说：要访问的对象在远程的机器上。在面向对象系统中，有些对象因为某些缘由（好比对象建立开销很大，或者某些操做须要安全控制，或者须要进程外的访问），直接访问会给使用者或者系统结构带来不少麻烦，咱们能够在访问此对象时加上一个对此对象的访问层。

什么时候使用： 想在访问一个类时作一些控制。

如何解决： 增长中间层。

关键代码： 实现与被代理类组合。

应用实例：

1. Windows 里面的快捷方式。
2. 猪八戒去找高翠兰结果是孙悟空变的，能够这样理解：把高翠兰的外貌抽象出来，高翠兰本人和孙悟空都实现了这个接口，猪八戒访问高翠兰的时候看不出来这个是孙悟空，因此说孙悟空是高翠兰代理类。
3. 买火车票不必定在火车站买，也能够去代售点。
4. 一张支票或银行存单是帐户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人帐号上资金的控制。
5. spring aop。

优势：

1. 职责清晰。
2. 高扩展性。
3. 智能化。

缺点：

1. 因为在客户端和真实主题之间增长了代理对象，所以有些类型的代理模式可能会形成请求的处理速度变慢。
2. 实现代理模式须要额外的工做，有些代理模式的实现很是复杂。

使用场景： 按职责来划分，一般有如下使用场景：

1. 远程代理。
2. 虚拟代理。
3. Copy-on-Write 代理。
4. 保护（Protect or Access）代理。
5. Cache 代理。
6. 防火墙（Firewall）代理。
7. 同步化（Synchronization）代理。
8. 智能引用（Smart Reference）代理。

注意事项：

1. 和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。
2. 和装饰器模式的区别：装饰器模式为了加强功能，而代理模式是为了加以控制。

数据映射模式

在了解数据映射模式以前，先了解下数据映射，它是在持久化数据存储层（一般是关系型数据库）和驻于内存的数据表现层之间进行双向数据传输的数据访问层。
数据映射模式的目的是让持久化数据存储层、驻于内存的数据表现层、以及数据映射自己三者相互独立、互不依赖。这个数据访问层由一个或多个映射器（或者数据访问对象）组成，用于实现数据传输。通用的数据访问层能够处理不一样的实体类型，而专用的则处理一个或几个。
数据映射模式的核心在于它的数据模型遵循单一职责原则（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 进去。

应用实例：

1. 红楼梦中的 "击鼓传花"。
2. JS 中的事件冒泡。
3. JAVA WEB 中 Apache Tomcat 对 Encoding 的处理，Struts2 的拦截器，jsp servlet 的 Filter。

优势：

1. 下降耦合度。它将请求的发送者和接收者解耦。
2. 简化了对象。使得对象不须要知道链的结构。
3. 加强给对象指派职责的灵活性。经过改变链内的成员或者调动它们的次序，容许动态地新增或者删除责任。
4. 增长新的请求处理类很方便。

缺点：

1. 不能保证请求必定被接收。
2. 系统性能将受到必定影响，并且在进行代码调试时不太方便，可能会形成循环调用。
3. 可能不容易观察运行时的特征，有碍于除错。

使用场景：

1. 有多个对象能够处理同一个请求，具体哪一个对象处理该请求由运行时刻自动肯定。
2. 在不明确指定接收者的状况下，向多个对象中的一个提交一个请求。
3. 可动态指定一组对象处理请求。

注意事项： 在 JAVA WEB 中遇到不少应用。

命令模式

命令模式（Command Pattern）是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找能够处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。

介绍

意图： 将一个请求封装成一个对象，从而使您能够用不一样的请求对客户进行参数化。

主要解决： 在软件系统中，行为请求者与行为实现者一般是一种紧耦合的关系，但某些场合，好比须要对行为进行记录、撤销或重作、事务等处理时，这种没法抵御变化的紧耦合的设计就不太合适。

什么时候使用： 在某些场合，好比要对行为进行 "记录、撤销 / 重作、事务" 等处理，这种没法抵御变化的紧耦合是不合适的。在这种状况下，如何将 "行为请求者" 与 "行为实现者" 解耦？将一组行为抽象为对象，能够实现两者之间的松耦合。

如何解决： 经过调用者调用接受者执行命令，顺序：调用者→接受者→命令。

关键代码： 定义三个角色：

1. received 真正的命令执行对象
2. Command
3. invoker 使用命令对象的入口

应用实例： struts 1 中的 action 核心控制器 ActionServlet 只有一个，至关于 Invoker，而模型层的类会随着不一样的应用有不一样的模型类，至关于具体的 Command。

优势：

1. 下降了系统耦合度。
2. 新的命令能够很容易添加到系统中去。

缺点： 使用命令模式可能会致使某些系统有过多的具体命令类。

使用场景： 认为是命令的地方均可以使用命令模式，好比：

1. GUI 中每个按钮都是一条命令。
2. 模拟 CMD。

注意事项： 系统须要支持命令的撤销 (Undo) 操做和恢复 (Redo) 操做，也能够考虑使用命令模式，见命令模式的扩展。

解释器模式

解释器模式（Interpreter Pattern）提供了评估语言的语法或表达式的方式，它属于行为型模式。这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被用在 SQL 解析、符号处理引擎等。

介绍

意图： 给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。

主要解决： 对于一些固定文法构建一个解释句子的解释器。

什么时候使用： 若是一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就能够构建一个解释器，该解释器经过解释这些句子来解决该问题。

如何解决： 构建语法树，定义终结符与非终结符。

关键代码： 构建环境类，包含解释器以外的一些全局信息，通常是 HashMap。

应用实例： 编译器、运算表达式计算。

优势：

1. 可扩展性比较好，灵活。
2. 增长了新的解释表达式的方式。
3. 易于实现简单文法。

缺点：

1. 可利用场景比较少。
2. 对于复杂的文法比较难维护。
3. 解释器模式会引发类膨胀。
4. 解释器模式采用递归调用方法。

使用场景：

1. 能够将一个须要解释执行的语言中的句子表示为一个抽象语法树。
2. 一些重复出现的问题能够用一种简单的语言来进行表达。
3. 一个简单语法须要解释的场景。

注意事项： 可利用场景比较少，JAVA 中若是碰到能够用 expression4J 代替。

迭代器模式

迭代器模式（Iterator Pattern）是 Java 和 .Net 编程环境中很是经常使用的设计模式。这种模式用于顺序访问集合对象的元素，不须要知道集合对象的底层表示。
迭代器模式属于行为型模式。

介绍

意图： 提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。

主要解决： 不一样的方式来遍历整个整合对象。

什么时候使用： 遍历一个聚合对象。

如何解决： 把在元素之间游走的责任交给迭代器，而不是聚合对象。

关键代码： 定义接口：hasNext, next。

应用实例： JAVA 中的 iterator。

优势：

1. 它支持以不一样的方式遍历一个聚合对象。
2. 迭代器简化了聚合类。
3. 在同一个聚合上能够有多个遍历。
4. 在迭代器模式中，增长新的聚合类和迭代器类都很方便，无须修改原有代码。

缺点： 因为迭代器模式将存储数据和遍历数据的职责分离，增长新的聚合类须要对应增长新的迭代器类，类的个数成对增长，这在必定程度上增长了系统的复杂性。

使用场景：

1. 访问一个聚合对象的内容而无须暴露它的内部表示。
2. 须要为聚合对象提供多种遍历方式。
3. 为遍历不一样的聚合结构提供一个统一的接口。

注意事项： 迭代器模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既能够作到不暴露集合的内部结构，又可以让外部代码透明地访问集合内部的数据。

中介者模式

中介者模式（Mediator Pattern）是用来下降多个对象和类之间的通讯复杂性。这种模式提供了一个中介类，该类一般处理不一样类之间的通讯，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。

介绍

意图： 用一个中介对象来封装一系列的对象交互，中介者使各对象不须要显式地相互引用，从而使其耦合松散，并且能够独立地改变它们之间的交互。

主要解决： 对象与对象之间存在大量的关联关系，这样势必会致使系统的结构变得很复杂，同时若一个对象发生改变，咱们也须要跟踪与之相关联的对象，同时作出相应的处理。

什么时候使用： 多个类相互耦合，造成了网状结构。

如何解决： 将上述网状结构分离为星型结构。

关键代码： 对象 Colleague 之间的通讯封装到一个类中单独处理。

应用实例：

1. 中国加入 WTO 以前是各个国家相互贸易，结构复杂，如今是各个国家经过 WTO 来互相贸易。
2. 机场调度系统。
3. MVC 框架，其中 C（控制器）就是 M（模型）和 V（视图）的中介者。

优势：

1. 下降了类的复杂度，将一对多转化成了一对一。
2. 各个类之间的解耦。
3. 符合迪米特原则。

缺点： 中介者会庞大，变得复杂难以维护。

使用场景：

1. 系统中对象之间存在比较复杂的引用关系，致使它们之间的依赖关系结构混乱并且难以复用该对象。
2. 想经过一个中间类来封装多个类中的行为，而又不想生成太多的子类。

注意事项： 不该当在职责混乱的时候使用。

备忘录模式

备忘录模式（Memento Pattern）保存一个对象的某个状态，以便在适当的时候恢复对象。备忘录模式属于行为型模式。

介绍

意图： 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象以外保存这个状态。

主要解决： 所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象以外保存这个状态，这样能够在之后将对象恢复到原先保存的状态。

什么时候使用： 不少时候咱们老是须要记录一个对象的内部状态，这样作的目的就是为了容许用户取消不肯定或者错误的操做，可以恢复到他原先的状态，使得他有 "后悔药" 可吃。

如何解决： 经过一个备忘录类专门存储对象状态。

关键代码： 客户不与备忘录类耦合，与备忘录管理类耦合。

应用实例：

1. 后悔药。
2. 打游戏时的存档。
3. Windows 里的 ctri + z。
4. IE 中的后退。
5. 数据库的事务管理。

优势：

1. 给用户提供了一种能够恢复状态的机制，能够使用户可以比较方便地回到某个历史的状态。
2. 实现了信息的封装，使得用户不须要关心状态的保存细节。

缺点： 消耗资源。若是类的成员变量过多，势必会占用比较大的资源，并且每一次保存都会消耗必定的内存。

使用场景：

1. 须要保存 / 恢复数据的相关状态场景。
2. 提供一个可回滚的操做。

注意事项：

1. 为了符合迪米特原则，还要增长一个管理备忘录的类。
2. 为了节约内存，可以使用原型模式 + 备忘录模式。

观察者模式

当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。好比，当一个对象被修改时，则会自动通知它的依赖对象。观察者模式属于行为型模式。

介绍

意图： 定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，全部依赖于它的对象都获得通知并被自动更新。

主要解决： 一个对象状态改变给其余对象通知的问题，并且要考虑到易用和低耦合，保证高度的协做。

什么时候使用： 一个对象（目标对象）的状态发生改变，全部的依赖对象（观察者对象）都将获得通知，进行广播通知。

如何解决： 使用面向对象技术，能够将这种依赖关系弱化。

关键代码： 在抽象类里有一个 ArrayList 存放观察者们。

应用实例：

1. 拍卖的时候，拍卖师观察最高标价，而后通知给其余竞价者竞价。
2. 西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动做。

优势：

1. 观察者和被观察者是抽象耦合的。
2. 创建一套触发机制。

缺点：

1. 若是一个被观察者对象有不少的直接和间接的观察者的话，将全部的观察者都通知到会花费不少时间。
2. 若是在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能致使系统崩溃。
3. 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

使用场景：

1. 一个抽象模型有两个方面，其中一个方面依赖于另外一个方面。将这些方面封装在独立的对象中使它们能够各自独立地改变和复用。
2. 一个对象的改变将致使其余一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，能够下降对象之间的耦合度。
3. 一个对象必须通知其余对象，而并不知道这些对象是谁。
4. 须要在系统中建立一个触发链，A 对象的行为将影响 B 对象，B 对象的行为将影响 C 对象……，能够使用观察者模式建立一种链式触发机制。

注意事项：

1. JAVA 中已经有了对观察者模式的支持类。
2. 避免循环引用。
3. 若是顺序执行，某一观察者错误会致使系统卡壳，通常采用异步方式。

状态模式

在状态模式（State Pattern）中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。
在状态模式中，咱们建立表示各类状态的对象和一个行为随着状态对象改变而改变的 context 对象。

介绍

意图： 容许对象在内部状态发生改变时改变它的行为，对象看起来好像修改了它的类。

主要解决： 对象的行为依赖于它的状态（属性），而且能够根据它的状态改变而改变它的相关行为。

什么时候使用： 代码中包含大量与对象状态有关的条件语句。

如何解决： 将各类具体的状态类抽象出来。

关键代码： 一般命令模式的接口中只有一个方法。而状态模式的接口中有一个或者多个方法。并且，状态模式的实现类的方法，通常返回值，或者是改变实例变量的值。也就是说，状态模式通常和对象的状态有关。实现类的方法有不一样的功能，覆盖接口中的方法。状态模式和命令模式同样，也能够用于消除 if...else 等条件选择语句。

应用实例：

1. 打篮球的时候运动员能够有正常状态. 不正常状态和超常状态。
2. 曾侯乙编钟中，'钟是抽象接口','钟 A'等是具体状态，'曾侯乙编钟'是具体环境（Context）。

优势：

1. 封装了转换规则。
2. 枚举可能的状态，在枚举状态以前须要肯定状态种类。
3. 将全部与某个状态有关的行为放到一个类中，而且能够方便地增长新的状态，只须要改变对象状态便可改变对象的行为。
4. 容许状态转换逻辑与状态对象合成一体，而不是某一个巨大的条件语句块。
5. 可让多个环境对象共享一个状态对象，从而减小系统中对象的个数。

缺点：

1. 状态模式的使用必然会增长系统类和对象的个数。
2. 状态模式的结构与实现都较为复杂，若是使用不当将致使程序结构和代码的混乱。
3. 状态模式对 "开闭原则" 的支持并不太好，对于能够切换状态的状态模式，增长新的状态类须要修改那些负责状态转换的源代码，不然没法切换到新增状态，并且修改某个状态类的行为也需修改对应类的源代码。

使用场景：

1. 行为随状态改变而改变的场景。
2. 条件、分支语句的代替者。

注意事项： 在行为受状态约束的时候使用状态模式，并且状态不超过 5 个。

空对象模式

在空对象模式（Null Object Pattern）中，一个空对象取代 NULL 对象实例的检查。Null 对象不是检查空值，而是反应一个不作任何动做的关系。这样的 Null 对象也能够在数据不可用的时候提供默认的行为。
在空对象模式中，咱们建立一个指定各类要执行的操做的抽象类和扩展该类的实体类，还建立一个未对该类作任何实现的空对象类，该空对象类将无缝地使用在须要检查空值的地方。

策略模式

在策略模式（Strategy Pattern）中，一个类的行为或其算法能够在运行时更改。这种类型的设计模式属于行为型模式。
在策略模式中，咱们建立表示各类策略的对象和一个行为随着策略对象改变而改变的 context 对象。策略对象改变 context 对象的执行算法。

介绍

意图： 定义一系列的算法, 把它们一个个封装起来, 而且使它们可相互替换。

主要解决： 在有多种算法类似的状况下，使用 if...else 所带来的复杂和难以维护。

什么时候使用： 一个系统有许多许多类，而区分它们的只是他们直接的行为。

如何解决： 将这些算法封装成一个一个的类，任意地替换。

关键代码： 实现同一个接口。

应用实例：

1. 诸葛亮的锦囊妙计，每个锦囊就是一个策略。
2. 旅行的出游方式，选择骑自行车. 坐汽车，每一种旅行方式都是一个策略。
3. JAVA AWT 中的 LayoutManager。

优势：

1. 算法能够自由切换。
2. 避免使用多重条件判断。
3. 扩展性良好。

缺点：

1. 策略类会增多。
2. 全部策略类都须要对外暴露。

使用场景：

1. 若是在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式能够动态地让一个对象在许多行为中选择一种行为。
2. 一个系统须要动态地在几种算法中选择一种。
3. 若是一个对象有不少的行为，若是不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。

注意事项： 若是一个系统的策略多于四个，就须要考虑使用混合模式，解决策略类膨胀的问题。

模板模式

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式 / 模板。它的子类能够按须要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。

介绍

意图： 定义一个操做中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类能够不改变一个算法的结构便可重定义该算法的某些特定步骤。

主要解决： 一些方法通用，却在每个子类都从新写了这一方法。

什么时候使用： 有一些通用的方法。

如何解决： 将这些通用算法抽象出来。

关键代码： 在抽象类实现，其余步骤在子类实现。

应用实例：

1. 在造房子的时候，地基、走线、水管都同样，只有在建筑的后期才有加壁橱加栅栏等差别。 2. 西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。
2. spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，好比开启事务. 获取 Session. 关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就能够保存。

优势：

1. 封装不变部分，扩展可变部分。
2. 提取公共代码，便于维护。
3. 行为由父类控制，子类实现。

缺点： 每个不一样的实现都须要一个子类来实现，致使类的个数增长，使得系统更加庞大。

使用场景：

1. 有多个子类共有的方法，且逻辑相同。
2. 重要的、复杂的方法，能够考虑做为模板方法。

注意事项： 为防止恶意操做，通常模板方法都加上 final 关键词。

访问者模式

在访问者模式（Visitor Pattern）中，咱们使用了一个访问者类，它改变了元素类的执行算法。经过这种方式，元素的执行算法能够随着访问者改变而改变。这种类型的设计模式属于行为型模式。根据模式，元素对象已接受访问者对象，这样访问者对象就能够处理元素对象上的操做。

介绍

意图： 主要将数据结构与数据操做分离。

主要解决： 稳定的数据结构和易变的操做耦合问题。

什么时候使用： 须要对一个对象结构中的对象进行不少不一样的而且不相关的操做，而须要避免让这些操做 "污染" 这些对象的类，使用访问者模式将这些封装到类中。

如何解决： 在被访问的类里面加一个对外提供接待访问者的接口。

关键代码： 在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。

应用实例： 您在朋友家作客，您是访问者，朋友接受您的访问，您经过朋友的描述，而后对朋友的描述作出一个判断，这就是访问者模式。

优势：

1. 符合单一职责原则。
2. 优秀的扩展性。
3. 灵活性。

缺点：

1. 具体元素对访问者公布细节，违反了迪米特原则。
2. 具体元素变动比较困难。
3. 违反了依赖倒置原则，依赖了具体类，没有依赖抽象。

使用场景：

1. 对象结构中对象对应的类不多改变，但常常须要在此对象结构上定义新的操做。
2. 须要对一个对象结构中的对象进行不少不一样的而且不相关的操做，而须要避免让这些操做 "污染" 这些对象的类，也不但愿在增长新操做时修改这些类。

注意事项： 访问者能够对功能进行统一，能够作报表、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;
    }
}

参考连接

• https://github.com/domnikl/DesignPatternsPHP
• https://laravelacademy.org/category/design-patterns
• http://www.runoob.com/design-pattern/design-pattern-tutorial.html