设计模式的精髓在于封装变化点，对设计模式的理解与掌握，不在于模式中各个类之间的关系理清，更不在于具体的语言，而在于模式面临的需求场景。要从发现需求变动，准确找到变化点，从如何封装它的角度去研究，去学习，而不要拘泥于具体的形式。
下面对设计模式进行一个整体的小结：
GOF设计模式划分为创建型、结构型和行为型。
创建型模式是创建对象而不是直接实例化对象，这会使程序在判断给定情况下创建哪一个对象时更为灵活。
结构型模式可以将一组对象组合成更大的结构，例如复杂的用户界面或报表数据。
行为型模式定义系统内对像间的通信，以及复杂程序中的流程控制。
创建型：
抽象工厂：创建一系列“相关或者相互依赖的对象”。
使用场景：
系统中有多个产品族。
客户不需要知道要对象的创建过程。
客户使用的对象存在变动的可能，或者根本就不知道使用哪一个具体的对象。
构建器模式：创建一个复杂的对象。
使用场景：
当需要创建的是一个产品，且该产品的内部表现比较复杂。
客户不需要知道产品的内部细节。
单件模式：为对象生成一个唯一的实例。
使用场景：
系统只要一个实例对象。
客户调用类的单个实例只允许使用一个公共访问点。
原型模式：通过对一个已存在的对象克隆来创建另一个相似的对象。
使用场景：
类的实例化是动态的。
类的实例对象只有一个或很少的几个组合状态。
结构型：
桥接模式：将抽象部分与实现部分分离，使它们都可以独立的变化。
使用场景：
避免抽象方法和其实现方法绑定在一起。
抽象接口和它的实现都需要扩展出子类以备使用。
变动实现的方法根本不会影响客户程序调用部分。
适配器模式：类的接口转换期望的另外一个接口，从而使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
使用场景：
对象需要利用现在的并且接口不兼容的类。
需要创建可重用的类以作其他接口不一定兼容的类。
需要使用若干个现在的子类但又不想派生这些子类的每一个接口。
装饰模式：不改变对象结构的情况下给对象添加新的职责。
使用场景：
给对象增加的职责在未来会发生改变。
用子类扩展功能不实际的情况下。
外观模式：为子系统中的一组接口提供一个一致的界面，其定义了一个高层接口，这个接口使得这一子系统更加容易使用。
使用场景：
需要复杂的子系统提供一个简单的接口。
客户与抽象的实现类中存在若干依赖。
子系统分层是必要的或架构要求的情况下。
享元模式：运用共享技术有效地支持大量细粒度的对象。
使用场景：
系统需要存在大量的对象而共享某些本质的、不变的信息。
对象可以同时用于多个环境下。
在每个实例下，享元可以作为一个独立的对象。
组合模式：组合多个对象形成树形结构，以表示整体－部分的结构层次。组合模式对单个对象和组合对象的使用具有一致性。
使用场景：
当需要表示一个对象的整体或部分层次。
想让客户忽略不同对象的层次变化。
对象的结构是动态的并且复杂程度不一样，但客户需要一致的处理它们。
代理模式：代理模式（Proxy）的目标是为其他对象提供一个代理或地方以控制对这个对象的访问。当客户向代理对象第一次提出请求时，代理实例化真实对象，并且将请求传给它，以后所有客户请求都经由代理传给真实对象。
使用场景：
虚拟代理、远程代理、安全代理、聪明引用。
行为型：
模版模式：定义一个操作中算法的骨架，将一些步骤的执行延迟到其子类中。
使用场景：
需要将相同的算法放在一个类中，将算法变化的部分放在子类中实现。
子类公共的算法应该放在一个公共类中，避免代码重复。
责任链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。
使用场景：
超过一个对象能够处理客户请求并且到底哪个对象处理。
一个请求可以发布到多个对象但它的接收都是不清晰。
可以动态指定一组对象处理请求。
命令模式：将一个请求封装成一个对象，因此可以参数化多个客户的不同请求，将请求排除，记录请求日志，并支持撤消操作。
使用场景：
需要与动作有关的对象来作为参数。
需要在不同的时间创建请求，生成请求队列，执行请求。
需要支持取消、保存或处理事务的功能。
需要支持宏命令。
解释器模式：给出一种语言，定义这种语言的文法的一种表示，定义一个解释器，用它来解释使用这种语言的句子。
使用场景：
语言的文法需要扩展。
迭代器模式：提供一种方法可以访问聚合对象，而不用暴露这个对象的内部表示。
使用场景：
需要遍历访问聚集中的对象而不能暴露聚集的内部结构。
允许对聚集的多级遍历访问而不会相互受影响。
提供一个一致的接口来遍历访问聚集中不同的结构。
中介模式：定义一个对象封装一系列多个对象如何相互作用，使得对象间不需要显式地相互引用，从而使其耦合更加松散，并且还让我们可以独立变化多个对象相互作用。
使用场景：
一组对象复杂地相互通信但其方法是定义明确的。
若干个对象需要定义方法又不需要子类实现。
观察者模式：定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。
使用场景：
一个对象的变化请求需要其他对象也变化，并且其他要变化对象的数量不明确。
一个对象需要通知其他对象而不需要掌握其他对象的识别方法。
备忘模式：在不破坏封闭的前提下，捕获并保存一个对象的内部状态，这样可以将对象恢复到原先的状态。
使用场景：
对象状态的备忘足以使对象可以完全恢复到原来的状态。
状态模式：允许一个对象在其内部状态改变的时候改变行为。
使用场景：
对象的行为于它的状态，并且它必须可以根据它的状态而改变行为。
系统存在大量的条件判断语句。
策略模式：定义一系列算法，将每个算法封装起来，并让他们可以相互替换。策略模式让算法独立于使用它的客户而变化。
使用场景：
多个类的分别只是在于行为不同。
需要对行为的算法作很多变动。
客户不知道算法要使用的数据。
访问者模式：分离对象数据结构与行为的方法，通过这种分离，可以为一个已存在的类或类群增加新的操作而无需为它们作任何修改。
使用场景：
一个对象的结构包含多个不同接口的对象，并且需要根据具体对象作不同的处理。
对结构中的对象有很多不同且没有联系的处理，因此需要避免操作将类分离。
类中定义的对象结构很少改变，但你需要经常地定义处理结构的新操作。