深入解析：23种软件设计模式详解及其分类（创建型、结构型、行为型）附代码示例DEMO

目录

引言

一、创建型模式

1. 简单工厂模式（Simple Factory Pattern）

2. 抽象工厂模式（Abstract Factory Pattern）

3. 单例模式（Singleton Pattern）

4. 建造者模式（Builder Pattern）

5. 原型模式（Prototype Pattern）

二、结构型模式

1. 适配器模式（Adapter Pattern）

2. 桥接模式（Bridge Pattern）

3. 装饰器模式（Decorator Pattern）

4. 组合模式（Composite Pattern）

5. 外观模式（Facade Pattern）

6. 享元模式（Flyweight Pattern）

7. 代理模式（Proxy Pattern）

三、行为型模式

1. 策略模式（Strategy Pattern）

2. 模板方法模式（Template Method Pattern）

3. 观察者模式（Observer Pattern）

4. 迭代器模式（Iterator Pattern）

5. 职责链模式（Chain of Responsibility Pattern）

6. 命令模式（Command Pattern）

7. 备忘录模式（Memento Pattern）

8. 状态模式（State Pattern）

9. 访问者模式（Visitor Pattern）

10. 中介者模式（Mediator Pattern）

11. 解释器模式（Interpreter Pattern）

---

引言

在软件开发领域，设计模式是一种经过反复验证和广泛使用的最佳实践。它们提供了对常见问题的标准解决方案，旨在提高代码的可重用性、可读性和可维护性。本文将详细介绍23种设计模式，按照创建型、结构型和行为型三大类别进行分类阐述。

一、创建型模式

1. 简单工厂模式（Simple Factory Pattern）

简单工厂模式又称为静态工厂方法模式，它定义了一个工厂类，这个类根据传入的参数不同返回不同类的实例。这些实例通常都具有共同的父类或接口。简单工厂模式的核心在于将对象的创建逻辑封装在工厂类中，客户端通过调用工厂类的静态方法来获取所需的对象，而无需直接实例化具体产品类。

传送门：【设计模式】——简单工厂模式（Simple Factory Pattern）

2. 抽象工厂模式（Abstract Factory Pattern）

抽象工厂模式是所有形态的工厂模式中最抽象和最具一般性的一种。它适用于处理具有产品族（即一组相互关联或相互依赖的产品）的产品结构。产品族是指位于不同等级结构中的一组产品，它们之间可能存在一定的依赖或约束关系。抽象工厂模式通过定义一个接口，使得客户端可以在不必指定具体产品的情况下，创建多个产品族中的产品对象。

传送门：【设计模式】——抽象工厂模式（Abstract Factory Pattern）

3. 单例模式（Singleton Pattern）

单例模式的核心思想是确保一个类仅有一个实例，并提供一个全局访问点来获取这个实例。它通过私有化构造函数和拷贝构造函数（以及赋值操作符，如果适用），并提供一个静态方法来创建和返回类的唯一实例，来实现这一目标。

传送门：【设计模式】——单例模式（Singleton Pattern）

4. 建造者模式（Builder Pattern）

建造者模式的核心思想是将一个复杂对象的构建过程与它的表示分离，使得同样的构建过程可以创建出不同的表示。它允许用户通过指定复杂对象的类型和内容来构建它们，而无需知道对象内部的具体构建细节。建造者模式隐藏了复杂对象的创建细节，通过一步一步构建一个复杂的对象，使得构建过程更加清晰和易于控制。

传送门：【设计模式】——建造者模式（Builder Pattern）

5. 原型模式（Prototype Pattern）

原型模式的核心思想是通过复制一个已存在的对象（原型）来创建新的对象，而不是通过实例化类来创建。这种复制可以是浅拷贝（只复制对象的基本数据类型成员和引用类型成员的引用，不复制引用类型成员本身），也可以是深拷贝（完全复制对象及其所有成员，包括引用类型成员本身）。

传送门：【设计模式】——原型模式（Prototype Patter）

二、结构型模式

1. 适配器模式（Adapter Pattern）

适配器模式的核心思想在于将一个类的接口转换成客户端所期望的另一种接口，使得原本因接口不匹配而不能一起工作的类能够协同工作。这种转换是通过创建一个中间的适配器类来实现的，该适配器类负责将客户端的请求转换为被适配者类所能理解的请求，并将被适配者类的响应转换回客户端所能理解的格式。

传送门：【设计模式】——适配器模式（Adapter Pattern）

2. 桥接模式（Bridge Pattern）

桥接模式核心思想是将抽象部分与它的实现部分分离，使它们都可以独立地变化。这种分离方式允许我们分别关注抽象定义和实现细节，从而提高了系统的灵活性和可扩展性。桥接模式通过组合关系替代了传统的继承关系，减少了类之间的耦合度。这种分离方式类似于将一座桥分为桥面（抽象部分）和桥墩（实现部分），两者可以独立设计和变化，互不影响。

传送门：【设计模式】——桥接模式（Bridge Pattern）

3. 装饰器模式（Decorator Pattern）

装饰器模式的核心思想是通过组合而非继承来实现功能的扩展。它允许在运行时动态地给对象添加一些额外的职责（即增加其额外功能），而无需修改原有对象的代码。装饰器模式通过创建一个包装对象（即装饰器）来包裹真实对象，并在保持真实对象类结构不变的前提下，为其提供额外的功能。这种灵活性使得装饰器模式在需要对对象的行为进行动态修改的情况下非常有用。

传送门：【设计模式】——装饰器模式（Decorator Pattern）

4. 组合模式（Composite Pattern）

组合模式定义了一种将对象组合成树形结构以表示部分与整体层次的方式。它使得用户对单个对象和组合对象的使用具有一致性。组合模式的核心思想在于统一对象和对象集合的处理方式，通过实现相同的接口或继承相同的抽象类，使得客户端代码可以相同地处理单个对象和组合对象。

传送门：【设计模式】——组合模式（Composite Pattern）

5. 外观模式（Facade Pattern）

外观模式其核心思想是将一个复杂的子系统封装在一个外观类中，为子系统提供一个统一的接口。通过这个接口，客户端可以简化对子系统的访问，而无需直接与子系统中的各个组件进行交互。外观模式旨在减少系统的复杂性，提高系统的易用性和可维护性。

传送门：【设计模式】——外观模式（Facade Pattern）

6. 享元模式（Flyweight Pattern）

享元模式通过存储共享实例对象的地方称为享元池（Flyweight Pool），来避免频繁地创建和销毁对象。其核心思想是将对象的状态分为内部状态（Intrinsic State）和外部状态（Extrinsic State）。内部状态是对象不可变的共享部分，而外部状态是可以改变的独立部分。当多个客户端请求同一个享元对象时，它们实际上共享的是同一个对象，从而节省了内存空间。

传送门：【设计模式】——享元模式（Flyweight Pattern）

7. 代理模式（Proxy Pattern）

代理模式的核心思想是为其他对象提供一个代理，以控制对这个对象的访问。代理对象在客户端和目标对象之间起到中介的作用，可以拦截对实际对象的访问，并在访问前后执行额外的操作。代理模式主要分为静态代理和动态代理两种类型，其中动态代理在运行时动态生成代理类，更加灵活。

传送门：【设计模式】——代理模式（Proxy Pattern）

三、行为型模式

1. 策略模式（Strategy Pattern）

策略模式的核心思想是将算法的定义与使用分离，即将不同的算法封装成独立的类，并使它们可以相互替换。这样做的好处是可以在不修改客户端代码的情况下，通过替换算法类来改变算法的行为，从而提高系统的灵活性和可扩展性。策略模式遵循了开闭原则，即对扩展开放，对修改关闭，使得系统在不修改原有代码的基础上能够轻松地添加新的算法或修改现有算法。

传送门：【设计模式】——策略模式（Strategy Pattern）

2. 模板方法模式（Template Method Pattern）

模板方法模式在一个抽象类中公开定义了执行算法的模板。这个模板包含了一个或多个基本方法，这些基本方法的具体实现由子类提供。通过这种模式，子类可以在不改变算法结构的情况下，通过重写基本方法来实现算法的不同部分。

传送门：【设计模式】——模板方法模式（Template Method Pattern）

3. 观察者模式（Observer Pattern）

观察者模式其核心思想在于建立一种对象间的一对多依赖关系，使得当一个对象（被观察者）的状态发生改变时，所有依赖于它的对象（观察者）都会得到通知并自动更新。这种机制提供了一种灵活的、松耦合的方式来处理对象间的交互，使得系统更加易于维护和扩展。

传送门：【设计模式】——观察者模式（Observer Pattern）

4. 迭代器模式（Iterator Pattern）

迭代器模式的核心在于定义一个迭代器接口，这个接口中包含了访问和操作聚合对象元素的方法，如hasNext()和next()。聚合对象（即容器）负责创建迭代器的实例，并对外提供这个方法。客户端通过迭代器接口遍历聚合对象中的元素，而无需了解聚合对象的内部结构。

传送门：【设计模式】——迭代器模式（Iterator Pattern）

5. 职责链模式（Chain of Responsibility Pattern）

职责链模式的核心思想是将请求的发送者和接收者解耦，通过创建一个对象链来传递请求，直到链中的某个对象能够处理该请求为止。这种模式允许多个对象都有机会处理这个请求，或者将这个请求传递给链中的下一个对象。

传送门：【设计模式】——职责链模式（Chain of Responsibility Pattern）

6. 命令模式（Command Pattern）

命令模式的核心思想在于将请求封装成对象，这个对象包含了执行该请求所需的所有信息（如接收者、操作参数等）。通过这种方式，请求的发送者只需要知道如何发送命令，而不需要知道如何执行命令。接收者只需要知道如何执行命令，而不需要知道命令是从哪里发出的。命令模式的关键在于将请求的行为参数化，使得不同的请求可以在不同时间由不同的对象来处理。

传送门：【设计模式】——命令模式（Command Pattern）

7. 备忘录模式（Memento Pattern）

备忘录模式（Memento Pattern）的核心思想在于在不破坏封装性的前提下，捕获并保存一个对象的内部状态，以便在将来需要时能够将这些状态恢复到该对象上。这种设计模式特别适用于需要实现撤销/重做操作、事务管理或任何需要保存和恢复对象状态的场景。

传送门：【设计模式】——备忘录模式（Memento Pattern）

8. 状态模式（State Pattern）

状态模式允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。这个模式通过把状态的逻辑放到一系列的类中，并将请求委托给当前状态对象来工作，从而解决了在复杂对象中管理大量条件分支语句的问题。每个状态对象都是一个策略对象，封装了与特定状态相关的行为，并在状态之间切换时改变行为。

传送门：【设计模式】——状态模式（State Pattern）

9. 访问者模式（Visitor Pattern）

访问者模式表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。这是一种将数据操作与数据结构分离的设计模式。访问者模式适用于数据结构相对稳定，但经常需要在此数据结构上定义新的操作的情况。

传送门：【设计模式】——访问者模式（Visitor Pattern）

10. 中介者模式（Mediator Pattern）

中介者模式用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。这个模式在对象之间存在大量交互且这些交互导致难以理解和维护时特别有用。

传送门：【设计模式】——中介者模式（Mediator Pattern）

11. 解释器模式（Interpreter Pattern）

解释器模式给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。这个模式适用于实现一个简单的语言或复杂的文本处理任务，如表达式计算、文本格式化等。

传送门：【设计模式】——解释器模式（Interpreter Pattern）