在软件工程的漫长演进中，代码的可维护性与扩展性始终是开发者面临的终极挑战。面对日益复杂的业务逻辑，如何避免“牵一发而动全身”的代码耦合？如何在不修改原有代码的前提下轻松添加新功能？这些问题催生了设计模式这一概念。对于许多刚接触架构设计的开发者而言，最常被问到的基础问题莫过于：设计模式可以分为哪几类？一共有多少种主流的设计模式？ 这不仅仅是记忆几个名词，更是理解面向对象设计思想的核心钥匙。本文将深入剖析设计模式的分类体系，详细解读主流的23种模式，并结合实际开发场景，助你构建清晰的架构思维。
一、设计模式的起源与核心分类逻辑
提到设计模式，就不得不提1994年出版的《设计模式：可复用面向对象软件的基础》一书。这本书由四位作者（Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides）合著，被业界亲切地称为“四人帮”（GoF）之作。他们在书中系统性地总结了23种经典的设计模式，这些模式并非凭空臆造，而是从无数成功的软件项目中提炼出的最佳实践。
为了便于理解和应用，GoF根据模式解决的核心问题和关注点的不同，将这23种模式划分为三大阵营：创建型模式、结构型模式和行为型模式。这种分类方式直观地对应了软件设计的三个基本维度：对象是如何诞生的？对象之间是如何组合的？对象之间是如何交互协作的？
1.1 创建型模式：解耦对象的创建过程
在大型系统中，直接使用new关键字实例化对象往往会导致代码与具体类强耦合。一旦需要更换实现类，就必须修改大量调用代码。创建型模式的核心价值在于将对象的创建逻辑封装起来，使系统在决定创建什么对象、如何创建以及何时创建时拥有更大的灵活性。这类模式主要解决“对象创建太死板”、“初始化逻辑复杂”以及“依赖具体类”的痛点。
1.2 结构型模式：优化对象的组合结构
随着系统规模扩大，类与类之间的关系变得错综复杂。结构型模式关注如何将类或对象组合成更大的结构，就像搭积木一样，通过不同的组合方式（如适配、装饰、代理）来构建功能强大的复杂系统。它们主要处理类与类之间的继承关系或对象之间的组合关系，旨在降低耦合度，提高系统的灵活性和复用性。这类模式常用于解决“接口不兼容”、“功能扩展困难”以及“子系统调用繁琐”等问题。
1.3 行为型模式：规范对象的交互协作
软件不仅仅是静态的结构，更是动态的行为流。行为型模式关注对象之间的通信机制、职责分配以及算法的流动。它们描述了对象在运行时如何相互协作以完成复杂的业务流程，涉及控制流、状态管理、命令分发等逻辑。这类模式是解决“对象间耦合紧密”、“算法频繁切换”以及“请求处理链条过长”的关键手段，能够显著提升代码的可读性和可维护性。
二、五大创建型模式深度解析与应用
创建型模式共有5种，它们是构建灵活系统的地基。在实际开发中，合理运用这些模式可以极大地降低模块间的依赖。
2.1 单例模式（Singleton）：全局唯一的实例控制
单例模式确保一个类在整个应用程序生命周期中只有一个实例，并提供一个全局访问点。这在数据库连接池、线程池、日志管理器以及配置读取器等场景中应用极为广泛。通过私有化构造函数并利用静态变量存储实例，单例模式有效节省了系统资源并保证了全局状态的一致性。需要注意的是，在多线程环境下，必须采用双重检查锁定（DCL）或静态内部类等方式来保证线程安全，防止出现多个实例破坏单例原则。
2.2 工厂方法模式（Factory Method）：延迟实例化的决策权
工厂方法模式定义了一个创建对象的接口，但让子类决定实例化哪一个类。这使得类的实例化过程延迟到了子类进行。当系统需要支持多种不同类型的产品，且希望客户端代码不依赖于具体产品类时，工厂方法模式是绝佳选择。例如，在一个跨平台的UI框架中，不同的操作系统（Windows、Mac、Linux）需要创建不同的按钮对象，通过工厂方法模式，每个平台的具体工厂类负责创建对应的按钮，主程序只需依赖抽象工厂接口即可。
2.3 抽象工厂模式（Abstract Factory）：产品族的批量生产
如果说工厂方法是针对单一产品等级结构，那么抽象工厂模式则是针对多个产品等级结构（即产品族）。它提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。在涉及数据库切换（如同时切换MySQL和Oracle的连接、命令、事务对象）或主题皮肤切换（同时切换背景、字体、颜色等一组控件）的场景中，抽象工厂模式能确保客户端始终使用同一系列的产品，避免混用导致的不兼容问题。
2.4 建造者模式（Builder）：复杂对象的逐步构建
当一个对象的内部结构非常复杂，包含多个组成部分，且构建顺序固定但表示多样时，建造者模式应运而生。它将复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。在构建复杂的SQL语句、生成复杂的报表对象或配置庞大的网络请求参数时，建造者模式通过链式调用（Chain Calling）让代码变得清晰易读，避免了构造函数参数过多的“伸缩构造器”反模式。
2.5 原型模式（Prototype）：基于复制的高效创建
原型模式通过复制现有对象来创建新对象，而不是通过常规的实例化过程。对于那些初始化成本极高（如需要读取大量文件、连接网络或进行复杂计算）的对象，直接克隆一个已存在的实例往往比重新创建要高效得多。在图形编辑软件中，复制一个复杂的图形元素，或者在游戏开发中批量生成属性相似的敌人单位，原型模式都能发挥巨大作用。需要注意的是，深拷贝与浅拷贝的处理是实现该模式时的关键点。
三、七大结构型模式架构拆解
结构型模式共有7种，它们像胶水一样将各个独立的模块粘合在一起，形成稳固而灵活的系统架构。
3.1 适配器模式（Adapter）：接口转换的桥梁
适配器模式用于将一个类的接口转换成客户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以协同工作。这在集成第三方库、遗留系统改造或硬件驱动开发中极为常见。例如，系统需要一个USB-TypeC接口，但现有的设备只提供USB-TypeA接口，通过一个适配器类，就可以在不调用方代码的情况下实现兼容。适配器模式分为类适配器（利用多重继承）和对象适配器（利用组合），后者因符合“组合优于继承”原则而更受推崇。
3.2 桥接模式（Bridge）：抽象与实现的分离
桥接模式将抽象部分与它的实现部分分离，使它们都可以独立地变化。传统的继承关系会导致类爆炸（例如不同形状乘以不同颜色需要创建大量子类），而桥接模式通过组合的方式，将形状和颜色作为两个独立的维度进行扩展。在跨平台应用开发中，将业务逻辑（抽象）与平台特定实现（如Windows API、Linux API）分离，桥接模式能有效避免维度灾难，提升系统的可扩展性。
3.3 组合模式（Composite）：树形结构的统一处理
组合模式将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。在文件系统（文件与文件夹）、组织架构（员工与部门）或菜单系统中，组合模式允许客户端忽略叶子节点和枝节点的区别，统一进行操作。这种一致性大大简化了客户端代码，使其无需关心对象的层级深度。
3.4 装饰器模式（Decorator）：动态功能的增强
装饰器模式允许向一个现有的对象添加新的功能，同时又不改变其结构。相比于继承，装饰器模式提供了更灵活的扩展方式，可以在运行时动态地叠加多个功能。Java IO流库是装饰器模式的经典应用，通过层层包裹（如BufferedInputStream(new FileInputStream(...))），可以灵活地组合缓冲、加密、压缩等功能。在电商系统中，为商品动态添加“包邮”、“礼品包装”、“优先发货”等标签，装饰器模式也是理想的选择。
3.5 外观模式（Facade）：子系统的统一入口
外观模式为子系统中的一组接口提供一个一致的高层界面，使得子系统更容易使用。随着系统复杂度增加，外部调用者往往需要与多个子系统交互，流程繁琐且容易出错。外观模式通过提供一个统一的入口类，封装了内部的复杂交互逻辑，降低了耦合度。例如，一个“一键下单”接口背后可能涉及库存校验、订单创建、支付发起、物流通知等多个子系统，外观模式将这些细节隐藏起来，对外提供简洁的服务。
3.6 享元模式（Flyweight）：细粒度对象的共享
享元模式运用共享技术有效地支持大量细粒度的对象。当系统中存在大量相似对象，且这些对象的状态可以分离为“内部状态”（可共享）和“外部状态”（不可共享）时，享元模式能显著减少内存占用。文字编辑器中的字符对象、围棋棋盘上的棋子对象都是典型的应用场景。通过共享相同的字体、颜色等内部状态，系统只需维护少量的享元对象，从而大幅提升性能。
3.7 代理模式（Proxy）：访问控制的中间层
代理模式为其他对象提供一种代理以控制对这个对象的访问。代理对象可以在目标对象执行前后添加额外的操作，如权限校验、日志记录、缓存处理或延迟加载（虚拟代理）。Spring AOP（面向切面编程）的底层实现大量使用了代理模式。在远程服务调用（RPC）中，本地代理对象负责处理网络通信细节，对客户端屏蔽远程调用的复杂性，这也是代理模式的重要应用场景。
四、十一大行为型模式交互机制
行为型模式数量最多，共有11种，它们专注于对象间的通信与职责分配，是处理复杂业务逻辑的利器。
4.1 策略模式（Strategy）：算法的自由切换
策略模式定义了一系列的算法，并将每一个算法封装起来，使它们可以相互替换。这让算法的变化独立于使用算法的客户。在支付系统中，用户可以选择支付宝、微信、银行卡等多种支付方式，每种方式是一个具体的策略类。上下文环境根据用户的选择动态切换策略，避免了大量的if-else判断，符合开闭原则。
4.2 模板方法模式（Template Method）：算法骨架的复用
模板方法模式定义一个操作中的算法骨架，而将一些步骤延迟到子类中。这使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。在框架开发中极为常见，例如一个标准的数据处理流程（读取数据->处理数据->保存数据->日志记录），其中“处理数据”的具体逻辑由子类实现，而流程控制由父类模板方法固定。Servlet的生命周期处理也是典型的模板方法应用。
4.3 观察者模式（Observer）：事件驱动的联动机制
观察者模式定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这是实现事件驱动架构的基础。在消息队列、前端MVVM框架的数据绑定、以及微信公众号的消息推送系统中，观察者模式都扮演着核心角色。它实现了主体与观察者的解耦，使得系统易于扩展新的监听者。
4.4 迭代器模式（Iterator）：集合遍历的标准接口
迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。无论底层数据结构是数组、链表还是树，客户端都可以通过统一的迭代器接口进行遍历。Java中的Iterator接口及其实现是这一模式的典范，它屏蔽了不同集合类的内部差异，让遍历操作变得标准化和简单化。
4.5 责任链模式（Chain of Responsibility）：请求的多级处理
责任链模式使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。在审批流程（如请假审批：组长->经理->总监）、异常处理机制以及Netty的Pipeline处理中，责任链模式都能灵活地动态调整处理节点，增强系统的灵活性。
4.6 命令模式（Command）：请求的封装与撤销
命令模式将请求封装成对象，从而使可用不同的请求对客户进行参数化，支持对请求排队或记录请求日志，以及支持可撤消的操作。在GUI开发的菜单项、宏录制功能以及事务管理系统中，命令模式通过将操作封装为对象，实现了调用者与接收者的解耦，并天然支持撤销（Undo）和重做（Redo）功能。
4.7 备忘录模式（Memento）：状态的快照与恢复
备忘录模式在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后恢复。游戏存档、编辑器的“撤销”功能（配合命令模式）、数据库的事务回滚机制，都是备忘录模式的典型应用。它通过引入“发起人”、“备忘录”和“管理者”三个角色，巧妙地平衡了状态保存与封装性保护的需求。
4.8 状态模式（State）：状态驱动的行为变更
状态模式允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。这与策略模式结构相似，但意图不同：状态模式关注的是对象内部状态的变化导致行为的自动切换，而策略模式关注的是人为选择算法。在订单状态流转（待支付->已支付->发货->完成）、TCP连接状态管理中，状态模式能有效消除复杂的条件判断语句，使状态逻辑清晰独立。
4.9 访问者模式（Visitor）：结构与操作的分离
访问者模式表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。当对象结构相对稳定，但需要频繁对其施加新操作（如生成报表、语法分析、代码统计）时，访问者模式能将操作逻辑从数据结构中剥离出来，符合单一职责原则。不过，若对象结构频繁变动，该模式会导致大量修改，需谨慎使用。
4.10 中介者模式（Mediator）：网状关系的星型转化
中介者模式用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。在聊天室系统、航班调度系统或复杂的表单验证中，多个对象之间如果直接交互会形成复杂的网状结构，引入中介者后，所有交互都通过中介者进行，网状结构变为星型结构，极大降低了系统复杂度。
4.11 解释器模式（Interpreter）：语言文法的解析执行
解释器模式给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。在编译器、正则表达式引擎、SQL解析器以及自定义规则引擎中，解释器模式通过构建抽象语法树（AST）来解析和执行特定的语言逻辑。虽然适用场景相对垂直，但在涉及领域特定语言（DSL）开发时，它是不可或缺的工具。
五、模式选择的权衡与实战建议
掌握这23种主流设计模式，并不意味着要在每个项目中生搬硬套。过度设计往往比没有设计更糟糕。在实际开发中，应遵循“简单优先”的原则，只有当代码出现重复、耦合度过高或扩展困难时，再考虑引入相应的设计模式。
对于初学者，建议优先精通单例、工厂、策略、观察者、代理、装饰器、模板方法这几种高频模式，它们在JDK、Spring、MyBatis等主流框架中随处可见。理解这些模式的源码实现，比死记硬背类图更有价值。同时，要注意模式之间的组合使用，例如在构建复杂系统时，可能会同时用到工厂模式创建对象、装饰器模式增强功能、观察者模式处理事件，多种模式协同工作才能发挥出最大的效能。
设计模式是前人经验的总结，是解决特定问题的工具箱，而非束缚思维的教条。真正的架构能力，体现在对业务场景的深刻洞察，以及灵活运用这些工具去平衡性能、可读性与扩展性的艺术之中。
