原型模式 简介 用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象 从一个对象再创建另一个可定制的对象，而且不需要知道任何创建的细节 代码示例<?php abstract class Prototype {

简单工厂模式 简介 根据工厂的类型，实例化出类，通常采用swith结构，缺点是对修改没有封闭。 代码示例<?php /** * 简单工厂模式 * * 用一个工厂来创建我们所需要的类 * * Class Operation

观察者模式 简介 定义了一种一对多的依赖关系，让多个观察者对象同时监听一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使它们能够自动更新自己。 Subject 类，它把所有对观察者对象的引用保存在一个聚集里，每个主题都

备忘录模式 简介 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复都原先保存的状态。 备忘录模式比较适用于功能比较复杂的，但需要维护或记录属性历史的类，或者需要保存的属性只是众多属性

中介者模式 简介 用一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互 中介者模式很容易在系统中应用，也很容易在系统中误用。当系统出现了多对多交互复杂的对象群时，

简介当你在浏览器中输入 google.com 并且按下回车之后发生了什么？ 本文转自下面的文章： https://github.com/alex/what-happens-when https://github.com/skyline754

解释器模式 简介 给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子 当有一个语言需要解释执行，并且你可以将该语言中的句子表示为一个抽象语法树时，可以使用解释器模式。 代码示例<?ph

享元模式 简介 运用共享技术有效地支持大量细粒度的对象 享元模式可以避免大量非常相似类的开销，在程序设计中，有时需要生成大量细粒度的类实例来展示数据。如果发现这些实例除了几个参数外基本都是相同的，有时就能够大幅度地减少需要实例化的类的数

工厂方法模式 简介 定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到子类。 工厂方法克服了简单工厂违背了开放-封闭原则的缺点，又保持了封装对象创建过程的优点。工厂方法模式是简单工厂的进一步抽象和推广

外观模式 简介 为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用 首先，在设计初期阶段，应该要有意识的将不同的两个层分离，比如经典的MVC三层架构层与层之间建立外观 Facade

装饰模式 简介 动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活 当系统需要新功能的时候，是向旧的类中添加新的代码。这些新加的代码通常装饰了原有类的核心职责或者主要行为；在主类中加入了新的字段、新的方法和新

组合模式 简介 将对象组合成树形结构已表示部分-整体的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 当你发现需求中是体现部分与整体层次的结构时，以及你希望用户可以忽略组合对象与单个对象的不同，统一地使用组合结构中的所

命令模式 简介 将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作 第一，它能较容易地设计一个命令队列；第二，在需要的情况下，可以较容易的将命令计入日志；第三，允许接收请求的

职责链模式 简介 使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。 当客户提交一个请求时，请求时沿链传递直至有一个 Handler 对象负责处

建造者模式 简介 将一个复杂的对象的结构与它的表示分离，使得同样的构建过程可以创建不同的表示，而不需要知道具体的建造过程 主要用于创建一些复杂的对象，这些对象内部构建的建造顺序通常是稳定的，但对象内部的构建通常面临复杂的变化。 建造

桥接模式 简介 将抽象部分与它的实现部分分离，使它们都可以独立地变化 什么叫抽象与它的实现分离，这并不是说，让抽象类与其派生类分离，因为这没有任何意义实现指的是抽象类和它的派生类用来实现自己的对象手机可以按品牌分类，也可以按照功能分类，

适配器模式 简介 将一个类的接口转换成客户所希望的另外的接口。 Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 系统的数据和行为都正确，但是接口不符合时，我们应该考虑用适配器，目的是使控制范围之外的一个原

单一职责 就一个类而言，应该仅有一个引起它变化的原因。 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化产生时，设计会遭到意想不到的破坏。