「GOF设计模式」Gang of Four，四人帮。设计模式的经典书籍《设计模式——可复用面向对象软件的基础》是由四个人共同完成，故GOF设计模式特指该书中描述了23种经典的面向对象的设计模式。

模式分类

GOF提出的分类规则

模式可由两个维度进行分类

分类 目的（所做工作是属哪种类型）
创建型 结构性(处理类或对象间的组合) 行为型(描述类或对象的怎么交互、怎么分配职责)
范围 类 工厂方法模式 适配器模式(类) 解释器模式；模板方法模式
对象 抽象工厂模式；单例模式；
建造者模式、原型模式		 适配器模式(对象)；装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式 策略模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式

从目的来看

类别 说明
创建型模式 将对象的部分创建工作延迟到子类或者其他对象，从而应对需求变化为对象创建时具体类型实现引来的冲击
结构型模式 通过类继承或者对象组合获得更灵活的结构，从而应对需求变化为对象的结构带来的冲击
行为型模式 通过类继承或者对象组合来划分类与对象间的职责，从而应对需求变化为多个交互的对象带来的冲击

从范围来看（从实现手段来看）

  1. 类模式：处理类与子类的静态关系，偏向于继承方案
  2. 对象模式：处理对象间的动态关系，偏向于组合方案

    从封装变化角度对模式分类

    注意：比如Decorator、Bridge模式，我们把它们划到单一职责类别中，是因为二者在责任划分层次上表现的非常突出，但这不意味着其他模式没有责任问题。只不过是说这两个模式在责任划分中特征极其明显。
类别 说明 相关模式
组件协作 现代软件专业化分工之后的第一个结果就是“框架与应用程序的划分”。
“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式		 Template Method
Strategy
Observer/Event
单一职责 类与类之间责任划分的问题。
在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任		 Decorator
Bridge
对象创建 对象创建过程中的依赖问题。
通过“对象创建”模式来绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作		 Factory Method
Abstract Factory
Prototype
Builder
对象性能 面向对象很好地解决了“抽象”的问题，但是不可避免要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。 Singleton
Flyweight
接口隔离 在组件构建过程中，某些接口之间直接的依赖尝尝会带来很多问题、甚至根本无法实现。
采用添加一层间接（稳定）接口，来隔离本来互相紧密关联的接口时一种常见的解决方案
也是间接思想在某个层面上的应用		 Facade
Proxy
Mediator
Adapter
状态变化 在组件构建过程中，某些对象的状态经常面临变化，如何对这些变化进行有效的管理？同时又维护高层模块的稳定？“状态变化”模式为这一问题提供了一种解决方案 Memento
State
数据结构 常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件的复用。
这时候，将这些特定数据结构封装在内部，在外部提供统一的接口，来实现与特定数据结构无关的访问，是一种行之有效的解决方案		 Composite
Iterator
Chain of Resposibility
行为变化 在组件的构建过程中，组件行为的变化经常导致组件本身剧烈的变化。
“行为变化”模式将组件的行为和组件本身进行解耦，从而支持组件行为的变化，实现两者之间的松耦合。
- 类行为即是一个成员函数，函数本身是一种天然的编译式绑定，编译式绑定是非常非常紧耦合的
 Command
Visitor
领域问题 在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。 Interpreter