一.单一职责。保证一个类只有一个实例，并提供访问它的全局访问点。
何时采用
从代码角度来说，当你希望类只有一个实例的时候。
从应用角度来说，你希望有一个总管来负责某一件事情。并且这件事情的分配只能有一个人进行，如果有多个人进行肯定会弄乱。比如创建处理流水号如果有两个地方在创建的话是不是就会重复了呢？
二.抽象工厂。 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
何时采用
从代码角度来说，你希望在统一的地方创建一系列相互关联的对象，并且基于抽象对象的时候。
从应用角度来说，如果你的产品是成组成套的，并且肯定会不断扩展新系列的，那么就适用抽象工厂。比如说，外面买的塑料模型，里面总是有图纸、模型元件板和外壳包装三部分。那么生产模型的厂就是抽象工厂，打印图纸、打印包装盒以及生产元件板的三个流水线就是具体工厂了。需要生产新的模型，只需要制作新的图纸输入到三个流水线的电脑中就可以了。
三.使用工厂方法 。定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。
何时采用
从代码角度来说， 如果我们需要创建一个易变的对象，或是希望对象由子类决定创建哪个对象的时候可以考虑工厂方法。
从应用角度来说， 如果我们觉得具体产品的创建不稳定，或者客户端根本无需知道创建哪个具体产品的时候可以使用工厂方法。后者对于框架和工具包软件来说更常见，比如有一个打印类负责打印图纸，我们需要得到一个打印对象，对于调用方来说并不知道要使用超宽打印对象还是普通打印对象，我们可以通过工厂方法使客户端和抽象打印工厂直接沟通，由它来决定具体创建哪个打印对象。
四。使用原型实例。用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
何时采用
从代码角度来说， 如果你希望运行时指定具体类（比如是使用Footman作为敌人还是使用其它），或者你希望避免创建对象时的初始化过程（如果这个过程占用的时间和资源都非常多），或者是希望避免使用工厂方法来实现多态的时候，可以考虑原型模式。
从应用角度来说， 如果你创建的对象是多变化、多等级的产品，或者产品的创建过程非常耗时的时候（比如，有一定的计算量，或者对象创建时需要从网络或数据库中获取一定的数据），或者想把产品的创建独立出去，不想了解产品创建细节的时候可以考虑使用。不得不说，原型模式给了我们多一种创建对象，并且不依赖具体对象的选择。
五.建造者模式。 将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。
看起来建造者模式和抽象工厂模式差不多。 其实，建造者模式和抽象工厂模式的侧重点不同，前者强调一个组装的概念，一个复杂对象由多个零件组装而成并且组装是按照一定的标准射顺序进行的，而后者强调的是创建一系列产品。建造者模式适用于组装一台电脑，而抽象工厂模式适用于提供用户笔记本电脑、台式电脑和掌上电脑的产品系列。
何时采用
从代码角度来说， 如果你希望分离复杂类型构建规则和类型内部组成，或者希望把相同的构建过程用于构建不同类型的时候可以考虑使用建造者模式。
从应用角度来说， 如果你希望解耦产品的创建过程和产品的具体配件，或者你希望为所有产品的创建复用一套稳定并且复杂的逻辑的时候可以考虑使用建造者模式。
六.适配器模式.把一个类的接口变换成客户端所期待的另一种接口，从而使原本接口不匹配而无法在一起工作的两个类能够在一起工作。
何时采用
从代码角度来说， 如果需要调用的类所遵循的接口并不符合系统的要求或者说并不是客户所期望的，那么可以考虑使用适配器。
从应用角度来说， 如果因为产品迁移、合作模块的变动，导致双方一致的接口产生了不一致，或者是希望在两个关联不大的类型之间建立一种关系的情况下可以考虑适配器模式。
七.门面类型. 为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
何时采用
从代码角度来说， 如果你的程序有多个类是和一组其它接口发生关联的话可以考虑在其中加一个门面类型。
从应用角度来说， 如果子系统的接口是非常细的，调用方也有大量的逻辑来和这些接口发生关系，那么就可以考虑使用Facade把客户端与子系统的直接耦合关系进行化解。你可能会说，子系统改了门面不是照样改？的确是需要改，但是如果客户端本身的工作已经比较复杂，或者说可能有多个需要调用门面的地方，这个时候门面的好处就体现了。
八.代理模式. 为其他对象提供一种代理以控制对这个对象的访问。
Proxy(代理)、Facade以及Adapter可能都是对对象的一层封装，侧重点不同。Proxy基于一致的接口进行封装，Facade针对封装子系统，转化为高层接口，而Adapter的封装是处于适配接口的目的。
何时采用
代理模式应用非常广泛，如果你希望降低对象的使用复杂度、或是提升对象使用的友好度、或是提高对象使用的效率都可以考虑代理模式。
九.享元模式.运用共享技术有效地支持大量细粒度的对象。
何时采用
系统中有大量耗费了大量内存的细粒度对象，并且对外界来说这些对没有任何差别的（或者说经过改造后可以是没有差别的）。
十.组合模式。 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。
何时采用
从代码角度来说，如果类型之间组成了层次结构，你希望使用统一的接口来管理每一个层次的类型的时候。
从应用角度来说，如果你希望把一对多的关系转化为一对一的关系的时候。
十一.桥接模式。将抽象部分与实现部分分离，使它们都可以独立的变化。
何时采用
从代码角度来说，如果类型的继承是处于2个目的（违背单一职责原则）的话可以使用Bridge模式避免过多的子类。
从应用角度来说， 如果应用会在多个维度上进行变化，客户端希望两个维度（场景、游戏模式）的对象相对独立，动态耦合（客户端决定哪个场景和哪个游戏模式耦合）的时候可以考虑Bridge模式。
十二.装饰模式。 动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。
装饰模式和桥接模式的区别是，前者是针对功能的扩展，本质上还是一样东西，而后者针对多维护变化。装饰模式的思想在于扩展接口而桥接模式的思想是分离接口。
何时采用
从代码角度来说，如果你觉得由于功能的交叉扩展不会导致非常多的子类或者非常多的继承层次的话可以考虑装饰模式。
从应用角度来说，如果你希望动态给类赋予或撤销一些职责，并且可以任意排列组合这些职责的话可以使用装饰模式。
十三.模版方法。 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
何时采用
如果某些类型的操作拥有共同的实现骨架和不同的实现细节的话，可以考虑使用模版方法来封装统一的部分。
十四.策略模式。 定义一系列的算法，把它们一个一个封装起来，并且使它们可相互替换。本模式使得算法可以独立于它的客户而变化。
何时采用
从代码角度来说， 如果一个类有多种行为，并且在类内部通过条件语句来实现不同的行为的时候可以把这些行为单独封装为策略类。
从应用角度来说，如果系统需要选择多种算法中的一种并且希望通过统一的接口来获取算法的输出的话可以考虑策略模式。
十五.状态模式。允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。
何时采用
从代码角度来说，如果一个类有多种状态，并且在类内部通过的条件语句判断的类状态来实现不同行为时候可以把这些行为单独封装为状态类。
从应用角度来说，如果一个对象有多种状态，如果希望把对象状态的转化以及由不同状态产生的行为交给具体的状态类去做，那么可以考虑状态模式。
十六.责任链模式。 使多个对象都有机会处理请求，从而避免请求的发送者和接受者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象能处理请求为止。
何时采用
从代码角度来说，如果一个逻辑的处理由不同责任对象完成，客户端希望能自定义这个处理流程并且不希望直接和多个责任对象发生耦合的时候可以考虑责任链模式。
从应用角度来说，如果对一个事情的处理存在一个流程，需要经历不同的责任点进行处理，并且这个流程比较复杂或只希望对外公开一个流程的入口点的话可以考虑责任链模式。其实，责任链模式还可以在构架的层次进行应用，比如.NET中的层次异常处理关系就可以看作是一种责任链模式。
十七.命令模式。将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。
何时采用
有如下的需求可以考虑命令模式：
命令的发起人和命令的接收人有不同的生命周期。比如，下遗嘱的这种行为就是命令模式，一般来说遗嘱执行的时候命令的发起人已经死亡，命令是否得到有效的执行需要靠律师去做的。
希望能让命令具有对象的性质。比如，希望命令能保存以实现撤销；希望命令能保存以实现队列化操作。撤销的行为在GUI中非常常见，队列化命令在网络操作中也非常常见。
把命令提升到类的层次后我们对类行为的扩展就会灵活很多，别的不说，我们可以把一些创建型模式和结构型模式与命令模式结合使用。
十八。观察者模式。定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
何时采用
通过这个例子，我们就很容易理解观察者模式的适用点了：
一个对象的行为引发其它多个对象的行为。前者成为主体，后者称为观察者。
为了降低耦合，不希望主体直接调用观察者的方法，而是采用动态订阅主体事件的方式来进行自动的连锁响应行为。
为了增加灵活性，希望动态调整订阅主体事件的观察者，或者希望动态调整观察者订阅主体的事件。