Java 设计模式——分类及功能：从理论分类到实战场景映射

Java 设计模式——分类及功能：从理论分类到实战场景映射

设计模式的分类不是 “纸上谈兵的划分”，而是帮你快速定位 “解决问题的工具”—— 当你遇到 “如何灵活创建对象”“如何解耦复杂模块”“如何协调对象协作” 等问题时，能通过分类快速找到对应模式。本文不仅拆解分类逻辑，更会结合Java 实战场景，让你知道 “每种分类下的模式到底能解决什么项目问题”。

一、按目的分类：解决 “做什么” 的问题

这是最常用的分类方式，核心是根据模式的 “核心目标” 划分，直接对应项目开发中的三大核心需求：创建对象、组织结构、协调行为。

1. 创建型模式：解决 “对象创建” 的灵活性问题

核心特点：将 “对象创建” 与 “对象使用” 彻底分离，避免硬编码 new 对象导致的耦合，让创建逻辑可配置、可扩展。

项目痛点场景：如果在代码里到处写new UserService()，后续需要给UserService加构造参数、或切换为代理对象时，要改所有代码 —— 创建型模式就是解决这类问题。

包含模式及实战价值：

• 单例模式：Spring 中 Bean 默认单例的实现，避免频繁创建对象浪费资源（如配置类、工具类）；
• 原型模式：快速克隆复杂对象（如订单对象复制，避免重复 set 几十上百个属性）；
• 工厂方法模式：动态创建不同类型的产品（如根据支付类型，创建微信 / 支付宝支付实例）；
• 抽象工厂模式：创建 “产品族”（如创建 “Windows 系统 + MySQL 数据库” 的配套组件，或 “Linux 系统 + PostgreSQL” 的配套组件）；
• 建造者模式：分步构建复杂对象（如创建包含基础信息、商品列表、优惠规则的订单对象，按步骤组装）。

2. 结构型模式：解决 “模块 / 对象组合” 的扩展性问题

核心特点：通过特定的组合方式，将类或对象组装成更灵活的结构，应对需求变化时的 “最小改动”。

项目痛点场景：如果直接在 Controller 里写支付逻辑、日志逻辑、鉴权逻辑，代码会臃肿且难以修改 —— 结构型模式帮你 “拆分 + 组合” 这些模块。

包含模式及实战价值：

• 代理模式：Spring AOP 的底层核心，在不修改原代码的情况下增强功能（如日志记录、事务控制）；

• 适配器模式：统一第三方接口差异（如对接微信支付 V2、支付宝 V3 接口，用适配器封装成统一的支付接口）；

• 桥接模式：分离 “抽象逻辑” 与 “具体实现”（如消息发送功能，抽象层定义 “发送” 逻辑，实现层分别对接短信、邮件、推送）；

• 装饰模式：动态给对象加功能（如给基础的文件上传功能，装饰 “权限校验”“文件压缩”“进度监控” 功能）；

• 外观模式：给复杂子系统提供统一入口（如订单创建需要调用库存、支付、物流系统，用外观类封装成createOrder()一个方法）；

• 享元模式：复用大量相似对象（如系统中频繁创建的 “商品分类标签”，用享元池缓存，避免重复创建）；

• 组合模式：处理 “树形结构” 数据（如菜单管理，用组合模式统一处理单个菜单和菜单组的查询、删除）。

3. 行为型模式：解决 “对象协作” 的解耦问题

核心特点：定义对象间的交互规则，明确 “谁负责做什么”，避免对象间的直接依赖导致的代码混乱。

项目痛点场景：如果订单支付成功后，需要同步更新库存、发送通知、记录日志，直接在支付方法里调用这些逻辑，会导致耦合过高 —— 行为型模式帮你 “解耦协作关系”。

包含模式及实战价值：

• 模板方法模式：定义算法骨架（如导出 Excel 的流程：“查询数据→处理数据→写入 Excel→下载”，子类只需要实现 “查询数据” 步骤）；
• 策略模式：替换不同算法（如订单优惠计算，按 “满减”“折扣”“优惠券” 等策略动态切换计算逻辑）；
• 命令模式：封装请求（如订单的 “创建”“取消”“退款” 操作，封装成命令对象，支持撤销、日志记录）；
• 职责链模式：链式处理请求（如接口鉴权：“token 校验→权限校验→参数校验”，每个步骤是一个责任节点，依次处理）；
• 状态模式：根据对象状态动态改行为（如订单状态：“待支付→已支付→已发货→已完成”，不同状态下调用 “取消” 方法的逻辑不同）；
• 观察者模式：Spring 事件机制的核心，实现 “一对多” 通知（如支付成功后，通知库存系统、通知消息系统、通知统计系统）；
• 中介者模式：统一管理对象交互（如电商系统中，商品、订单、库存、用户的交互，用中介者类统一协调，避免相互依赖）；
• 迭代器模式：统一遍历集合（如自定义的 “商品列表” 集合，用迭代器封装遍历逻辑，支持正向、反向遍历）；
• 访问者模式：灵活扩展对象的访问方式（如商品数据的 “统计金额”“导出报表”“筛选库存不足” 操作，用访问者模式新增功能）；
• 备忘录模式：保存 / 恢复对象状态（如编辑器的 “撤销” 功能，保存文档的历史状态，支持回滚）；
• 解释器模式：解析特定语法（如自定义的 “优惠规则表达式”：“满 100 减 20 且包含会员商品”，用解释器解析并执行）。

二、按作用范围分类：解决 “静态 / 动态” 的适用场景问题

该分类聚焦模式的 “作用维度”—— 是基于类的继承（静态），还是基于对象的组合（动态），帮你判断模式的 “灵活度”。

1. 类模式：静态关联，编译时确定关系

核心特点：依赖类的继承关系，结构在编译时就固定，灵活性较低，但逻辑简单直接。

适用场景：需求稳定、不需要频繁修改的场景（如基础组件的固定流程）。

包含模式：工厂方法模式、（类）适配器模式、模板方法模式、解释器模式。

实战示例：用模板方法模式定义 “导出数据” 的固定流程（父类定义骨架，子类继承实现具体查询），编译时就确定了父类与子类的关系，后续不会频繁改动流程。

2. 对象模式：动态关联，运行时可调整

核心特点：依赖对象的组合 / 聚合关系，结构在运行时可动态变化，灵活性高，是项目中更常用的类型。​

适用场景：需求多变、需要灵活扩展的场景（如业务逻辑的动态切换）。​

包含模式：除上述 4 种类模式外，其余 19 种设计模式均属于对象模式。​

实战示例：用策略模式实现 “优惠计算”，运行时根据用户选择的优惠类型（满减 / 折扣），动态切换对应的策略对象，无需修改原有代码。