既然讲到了设计模式，那就先来解释下设计模式到底是个什么玩意。
设计模式，大家都知道源于建筑业，Christopher Alexander说过：“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。在面向对象的解决方案里，我们用对象和接口代替了墙壁和门墙。两类模式的核心都在于提供了相关问题的解决方案。
一般而言，一个模式都有四个基本要素：
模式名称（pattern name） 一个助记名，它用一两个词来描述模式的问题、解决方案和效果。说白了就像给小孩子起名字，总要有个好记又有点意义的名字来说明这个设计模式。当然这是个难事，给小孩起名也是嘛。
问题（problem） 描述了应该在何时使用模式。它解释了设计问题和问题存在的前因后果，它可能描述了特定的设计问题，如怎么样用对象表示算法等。也可能描述了导致不灵活的设计的类或对象结构。有时候，问题部分会包括使用模式必须满足的一系列先决条件。这点也是使用模式的重点，应用场景永远会是关注的重点。
解决方案（solution） 描述了设计的组成部分，它们之间的相互关系及各自的职责和协作方式。因为模式就像一个模板，可应用于多种场景，所以解决方案并不描述一个特定而具体的设计或实现，而是提供设计问题的抽象描述和怎样用一个具有一定意义的元素组合（类或对象组合）来解决问题。通俗的来类比，就是说解决方案是个目录，要知道具体内容，就要根据目录去找寻具体的内容了。
效果（consequences） 描述了模式应用的效果及使用模式应权衡的问题。尽管我们描述设计决策时，并不总是提到模式效果，但它们对于评价设计选择和理解使用设计模式的代价和好处具有重要意义。软件效果大多关注对时间和空间的衡量，它们表述了语言和实现问题。因为复用是面向对象设计的要素之一，所以模式效果包括它对系统的灵活性、扩充性或可移植性的影响，显式地列出这些效果对理解和评价这些设计模式很有帮助。这部分需要阐述的是使用具体一个模式的代价和价值，所以是我们权衡选择模式的根据。
一个设计模式命名、抽象和确定了一个通用设计结构的主要方面，这些设计结构能被用来构造可复用的面向对象设计。设计模式确定了所包含的类和实例，它们的角色、协作方式以及职责分配。
设计模式共有23个，它们的名字和意图列举如下：
Abstract Factory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
Adapter：将一个类的接口转换为客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
Bridge：将抽象部分与它的实现部分分离，使它们都可以独立的变化。
Builder：将一个复杂对象的构建和它的表示分离，使得同样的构建过程可以创建不同的表示。
Chain of Responsibility：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
Command：将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可取消的操作。
Composite：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得客户对单个对象和复用对象的使用具有一致性。
Decorator：动态地给一个对象添加一些额外的职责。就扩展功能而言，Decorator模式比生成子类方式更为灵活。
Facade：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
Factory Method：定义一个用于创建对象的接口，让子类决定将哪一类实例化。Factory Method使一个类的实例化延迟到其子类。
Flyweight：运用共享技术有效地支持大量细粒度的对象。
Interpreter：给定一个语言，定义它的文法的一种表示，并定义了一个解释器，该解释器使用该表示来解释语言中的句子。
Iterator：提供一种方法顺序访问一个聚合对象中各个元素，而又不需要暴露该对象的内部表示。
Mediator：用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
Mememto：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到保存之前的状态。
Observer：定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动刷新。
Prototype：用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
Proxy：为其他对象提供一个代理以控制对这个对象的访问。
Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
State：允许一个对象在起内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
Strategy：定义一系列算法，把它们一一封装起来，并且使它们可以互相替换。本模式使得算法的变化可独立于使用它的客户。
Template Method：定义了一个操作的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
Visitor：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
对上述这23中设计模式进行一个分类，以便于我们对各种相关的模式进行引用。
| 目的 | ||||
| 创建型 | 结构型 | 行为型 | ||
| 范围 | 类 | Factory Method | Adapter | Interpreter Template Method |
| 对象 | Abstract Factory Builder Prototype Singleton | Adapter Bridge Composite Decorator Facade Flyweight Proxy | Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor |
以目的为准则，即模式是用来完成什么工作的。创建型模式和对象的创建有关，结构型模式处理类或对象的组合，行为型模式对类或对象怎样交互和怎样分配职责进行描述。
以范围为准则，指定模式主要用于类还是用于对象。雷模式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了，对象模式处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性。
有些模式经常会被绑在一起使用，例如，Composite常和Iterator或Visitor一起使用；有些模式是可替代的，例如，Prototype常用来替代Abstract Factory；有些模式尽管意图不同，但产生的设计结果是很相似的，例如，Composite和Decorator的结构图是相似的。