设计模式有两种分类方法，即根据模式的目的来分和根据模式的作用的范围来分。
1. 根据目的来分
1.1.根据模式是用来完成什么工作来划分，这种方式可分为创建型模式、结构型模式和行为型模式 3 种。
- 创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF 中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。
- 结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF 中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。
- 行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责。GoF 中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。
J2EE 模式：这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。
MVC 模式（MVC Pattern）
业务代表模式（Business Delegate Pattern）
组合实体模式（Composite Entity Pattern）
数据访问对象模式（Data Access Object Pattern）
前端控制器模式（Front Controller Pattern）
拦截过滤器模式（Intercepting Filter Pattern）
服务定位器模式（Service Locator Pattern）
传输对象模式（Transfer Object Pattern）
1.2.设计模式的作用
1. 代码重用性(相同功能的代码,不需要多次编写)
2. 代码可读性(也就是编程规范性)
3. 代码可拓展性(当需要增加新的功能的时候,非非常的方便,也就是可维护性)
4. 代码可靠性(当我们增加新的功能后,对原有的功能没有影响)
5. 使得程序呈现高内聚低耦合的特性
设计模式的好处
帮助我们将应用组织成容易了解，容易维护，具有弹性的架构，建立可维护的OO系统，要诀在于随时想到系统以后可能需要的变化以及应付变化的原则。
设计模式事是程序员在面对同类软件工程设计问题所总结出来的有用的经验,模式不是代码,是某类问题的解决方案,设计模式代表了 最佳实践 这些解决方案是众多软件开发人员经过相当长的一段时间的实验和错误总结出来的 设计模式的本质提高 软件的维护性 通用性 和扩展性 并降低软件的复杂度 设计模式埠局限于某种语言
2. 根据作用范围来分
根据模式是主要用于类上还是主要用于对象上来分，这种方式可分为类模式和对象模式两种。
- 类模式：用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了。GoF中的工厂方法、（类）适配器、模板方法、解释器属于该模式。
- 对象模式：用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性。GoF 中除了以上 4 种，其他的都是对象模式。
表 1 介绍了这 23 种设计模式的分类。
| 范围目的 | 创建型模式 | 结构型模式 | 行为型模式 |
|---|---|---|---|
| 类模式 | 工厂方法 | (类）适配器 | 模板方法、解释器 |
| 对象模式 | 单例 原型 抽象工厂 建造者 |
代理 (对象）适配器 桥接 装饰 外观 享元 组合 |
策略 命令 职责链 状态 观察者 中介者 迭代器 访问者 备忘录 |
3. GoF的23种设计模式的功能
链接：https://www.zhihu.com/question/23757906/answer/208892917
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
创建型模式
这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用新的运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。
- 工厂模式与抽象工厂模式 （Factory Pattern）（Abstract Factory Pattern）：不同条件下创建不同实例
- 单例模式 （Singleton Pattern）：保证一个类仅有一个实例
- 建造者模式 （Builder Pattern）：将一个复杂的构建过程与其具表示细节相分离，使得同样的构建过程可以创建不同的表示
- 原型模式 （Prototype Pattern）：通过拷贝原型创建新的对象
结构型模式
这些设计模式关注类和对象的组合。
- 适配器模式 （Adapter Pattern）：使得原本由于接口不兼容而不能一起工作的那些类可以一起工作
- 装饰器模式 （Decorator Pattern）：保持接口，增强性能：修饰类继承被修饰对象的抽象父类，依赖被修饰对象的实例（被修饰对象依赖注入），以实现接口扩展
- 桥接模式 （Bridge Pattern）：两个维度独立变化，依赖方式实现抽象与实现分离：需要一个作为桥接的接口/抽象类，多个角度的实现类依赖注入到抽象类，使它们在抽象层建立一个关联关系
- 外观模式 （Facade Pattern）：在客户端和复杂系统之间再加一层，这一次将调用顺序、依赖关系等处理好。即封装底层实现，隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的高层接口
- 代理模式 （Proxy Pattern）：为其他对象提供一种代理以控制对这个对象的访问：增加中间层（代理层），代理类与底层实现类实现共同接口，并创建底层实现类对象（底层实现类对象依赖注入代理类），以便向外界提供功能接口
- 过滤器模式 （Filter、Criteria Pattern）：使用不同的标准来过滤一组对象，通过逻辑运算以解耦的方式把它们连接起来
- 组合模式 （Composite Pattern）：用户对单个对象和组合对象的使用具有一致性的统一接口
- 享元模式 （Flyweight Pattern）：享元工厂类控制；HashMap实现缓冲池重用现有的同类对象，如果未找到匹配的对象，则创建新对象
行为型模式
这些设计模式特别关注对象之间的通信。
- 责任链模式（Chain of Responsibility Pattern）：拦截的类都实现统一接口，每个接收者都包含对下一个接收者的引用。将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。
- 观察者模式（Observer Pattern）：一对多的依赖关系，在观察目标类里有一个 ArrayList 存放观察者们。当观察目标对象的状态发生改变，所有依赖于它的观察者都将得到通知，使这些观察者能够自动更新（即使用推送方式）
- 模板模式（Template Pattern）：将这些通用算法抽象出来，在一个抽象类中公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行
- 命令模式（Command Pattern）：将"行为请求者"与"行为实现者"解耦：调用者依赖命令，命令依赖接收者，调用者Invoker→命令Command→接收者Receiver
- 解释器模式（Interpreter Pattern）：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子
- 迭代器模式（Iterator Pattern）：集合中含有迭代器：分离了集合对象的遍历行为，抽象出一个迭代器类来负责，无须暴露该对象的内部表示
- 中介者模式（Mediator Pattern）：对象与对象之间存在大量的关联关系，将对象之间的通信关联关系封装到一个中介类中单独处理，从而使其耦合松散，可以独立地改变它们之间的交互
- 策略模式（Strategy Pattern）：策略对象依赖注入到context对象，context对象根据它的策略改变而改变它的相关行为(可通过调用内部的策略对象实现相应的具体策略行为)
- 状态模式（State Pattern）：状态对象依赖注入到context对象，context对象根据它的状态改变而改变它的相关行为(可通过调用内部的状态对象实现相应的具体行为)
- 备忘录模式（Memento Pattern）：通过一个备忘录类专门存储对象状态。客户通过备忘录管理类管理备忘录类。
- 空对象模式（Null Object Pattern）：创建一个未对该类做任何实现的空对象类，该空对象类将无缝地使用在需要检查空值的地方。不要为了屏蔽null而使用空对象，应保持用null，远比用非null的值来替代“无值”要好。（慎用）
4.设计模式的七大原则
1、开闭原则（Open Close Principle）
开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则是面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
3、依赖倒转原则（Dependence Inversion Principle）
这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
5、迪米特法则，又称最少知道原则（Demeter Principle）
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。
7、单一职责原则( Single Responsibility Principle)
一个类被改变的原因不能超过一个，也就是说，一个类只有一个职责，如果职责过多，代码就会臃肿，可读性更差，也更难以维护。其实上单一职责原则和接口隔离原则有一定的关系，接口隔离以后，职责就单一了，实现这个接口的类的职责自然也就单一了。但是接口隔离关注的是抽象层，单一职责关注的是两者兼而有之，偏重于实现。
5.什么是 GOF（四人帮，全拼 Gang of Four）？
在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。
四位作者合称 GOF（四人帮，全拼 Gang of Four）。他们所提出的设计模式主要是基于以下的面向对象设计原则。
对接口编程而不是对实现编程。
优先使用对象组合而不是继承。