【常用设计模式全解析】创建型模式（聚焦对象创建机制）、结构型模式（优化类与对象的组合关系）、行为型模式（规范对象间的交互行为）

引言

若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力！有问题请私信或联系邮箱：[e-mail]

在后端开发中，设计模式是解决重复问题的成熟方案，能够提升代码的可复用性、可扩展性和可维护性。合理运用设计模式不仅能简化复杂业务逻辑的实现，还能让团队协作更高效（基于统一的设计规范）。

后端开发涉及的设计模式主要分为三大类：创建型模式（聚焦对象创建机制）、结构型模式（优化类与对象的组合关系）、行为型模式（规范对象间的交互行为）。本文将针对每类模式中最常用的核心设计模式，从定义、应用场景、核心角色、代码实现到优缺点进行全面解析，并结合后端实际业务场景说明其落地方式。

一、创建型设计模式

创建型模式专注于对象创建的过程，通过封装对象创建的细节，降低代码间的耦合度。后端开发中最常用的创建型模式包括单例模式、工厂模式、建造者模式和原型模式。

1.1 单例模式（Singleton Pattern）

定义

确保一个类仅有一个实例，并提供一个全局访问点。

应用场景

• 全局配置类（如数据库连接配置、系统参数配置）
• 工具类（如日志工具、加密工具）
• 资源密集型对象（如线程池、连接池）

核心角色

• 单例类：负责创建自身实例，提供全局访问方法。

代码实现（线程安全的懒汉式）

public class Singleton {//  volatile 防止指令重排，确保实例初始化完成后再被访问private static volatile Singleton instance;// 私有构造方法，禁止外部实例化private Singleton() {}// 双重检查锁定，兼顾性能和线程安全public static Singleton getInstance() {if (instance == null) {synchronized (Singleton.class) {if (instance == null) {instance = new Singleton();}}}return instance;}
}

优缺点

优点	缺点
节省内存资源，避免重复创建对象	扩展性差，单例类通常不支持继承
提供全局统一访问点，简化数据共享	多线程环境下需额外处理线程安全问题
避免频繁创建销毁对象，提升性能	测试难度高，依赖全局状态可能导致测试污染

1.2 工厂模式（Factory Pattern）

工厂模式分为简单工厂、工厂方法和抽象工厂，核心是通过工厂类封装对象创建逻辑，降低客户端与具体产品的耦合。

1.2.1 简单工厂模式

定义

由一个工厂类根据传入的参数，动态创建不同产品类的实例。

应用场景

• 产品类型较少且固定的场景（如数据库驱动创建、支付方式选择）

核心角色

• 工厂类：负责创建所有产品的实例。
• 产品接口：定义产品的统一行为。
• 具体产品：实现产品接口的具体类。

代码实现

// 产品接口
public interface Payment {void pay(BigDecimal amount);
}// 具体产品：支付宝支付
public class Alipay implements Payment {@Overridepublic void pay(BigDecimal amount) {System.out.println("使用支付宝支付：" + amount + "元");}
}// 具体产品：微信支付
public class WechatPay implements Payment {@Overridepublic void pay(BigDecimal amount) {System.out.println("使用微信支付：" + amount + "元");}
}// 简单工厂类
public class PaymentFactory {public static Payment createPayment(String type) {switch (type) {case "alipay":return new Alipay();case "wechat":return new WechatPay();default:throw new IllegalArgumentException("不支持的支付方式");}}
}// 客户端使用
public class Client {public static void main(String[] args) {Payment payment = PaymentFactory.createPayment("alipay");payment.pay(new BigDecimal("100"));}
}

1.2.2 工厂方法模式

定义

定义一个创建产品的接口，由子类决定具体创建哪种产品，将产品创建延迟到子类。

应用场景

• 产品类型较多且可能扩展的场景（如消息队列生产者创建、日志框架适配）

代码实现（基于上述支付场景扩展）

// 工厂接口
public interface PaymentFactory {Payment createPayment();
}// 支付宝工厂
public class AlipayFactory implements PaymentFactory {@Overridepublic Payment createPayment() {return new Alipay();}
}// 微信支付工厂
public class WechatPayFactory implements PaymentFactory {@Overridepublic Payment createPayment() {return new WechatPay();}
}// 客户端使用
public class Client {public static void main(String[] args) {PaymentFactory factory = new AlipayFactory();Payment payment = factory.createPayment();payment.pay(new BigDecimal("100"));}
}

优缺点

优点	缺点
解耦对象创建与使用，客户端无需关注具体实现	简单工厂模式扩展困难，新增产品需修改工厂类（违反开闭原则）
便于产品扩展，符合开闭原则（工厂方法模式）	工厂方法模式会增加类的数量，提高系统复杂度
统一管理对象创建逻辑，便于维护	抽象工厂模式结构复杂，适合多产品族场景

1.3 建造者模式（Builder Pattern）

定义

将复杂对象的构建过程与表示分离，使得同样的构建过程可以创建不同的表示。

应用场景

• 复杂对象的创建（如订单对象、用户信息对象、配置对象）
• 对象属性较多且部分属性可选的场景

核心角色

• 产品：复杂对象本身。
• 建造者：定义构建产品的步骤和方法。
• 指挥者：负责调用建造者的方法，按顺序构建产品。

代码实现（构建订单对象）

// 产品：订单
@Data
public class Order {private Long orderId;private String userId;private BigDecimal amount;private String address;private List<String> products;private LocalDateTime createTime;
}// 建造者接口
public interface OrderBuilder {OrderBuilder setOrderId(Long orderId);OrderBuilder setUserId(String userId);OrderBuilder setAmount(BigDecimal amount);OrderBuilder setAddress(String address);OrderBuilder addProduct(String product);Order build();
}// 具体建造者
public class ConcreteOrderBuilder implements OrderBuilder {private Order order;public ConcreteOrderBuilder() {this.order = new Order();this.order.setCreateTime(LocalDateTime.now()); // 默认设置创建时间}@Overridepublic OrderBuilder setOrderId(Long orderId) {order.setOrderId(orderId);return this;}@Overridepublic OrderBuilder setUserId(String userId) {order.setUserId(userId);return this;}// 其他方法实现...@Overridepublic Order build() {// 校验必填属性if (order.getOrderId() == null || order.getUserId() == null) {throw new IllegalArgumentException("订单ID和用户ID不能为空");}return order;}
}// 客户端使用（可省略指挥者，直接通过建造者链式调用）
public class Client {public static void main(String[] args) {Order order = new ConcreteOrderBuilder().setOrderId(1001L).setUserId("funian").setAmount(new BigDecimal("999")).setAddress("成都").addProduct("手机").addProduct("耳机").build();System.out.println(order);}
}

优缺点

优点	缺点
分离复杂对象的构建与表示，灵活性高	系统复杂度增加，需新增建造者类
分步构建对象，支持可选属性配置	仅适用于复杂对象，简单对象使用成本高
便于扩展，新增产品变体只需新增建造者	建造者与产品耦合度较高

二、结构型设计模式

结构型模式关注类与对象的组合关系，通过合理的结构设计提升代码的灵活性和复用性。后端开发中常用的结构型模式包括代理模式、装饰器模式、适配器模式、外观模式和组合模式。

2.1 代理模式（Proxy Pattern）

定义

为其他对象提供一种代理以控制对这个对象的访问，常用于添加额外功能（如日志、权限校验、缓存）。

应用场景

• AOP 编程（如 Spring AOP）
• 权限控制（如接口访问权限校验）
• 缓存代理（如查询结果缓存）
• 远程代理（如 RPC 调用）

核心角色

• 目标对象：被代理的原始对象，提供核心业务逻辑。
• 代理对象：持有目标对象的引用，提供额外功能并调用目标对象的方法。
• 抽象主题：目标对象和代理对象共同实现的接口。

代码实现（静态代理 + 动态代理）

静态代理

// 抽象主题
public interface UserService {User getUserById(Long id);
}// 目标对象
public class UserServiceImpl implements UserService {@Overridepublic User getUserById(Long id) {System.out.println("查询用户信息，用户ID：" + id);return new User(id, "funian", 25);}
}// 代理对象（添加日志功能）
public class UserServiceProxy implements UserService {private UserService userService;public UserServiceProxy(UserService userService) {this.userService = userService;}@Overridepublic User getUserById(Long id) {// 前置增强：日志记录System.out.println("开始查询用户，时间：" + LocalDateTime.now());User user = userService.getUserById(id);// 后置增强：日志记录System.out.println("查询完成，用户信息：" + user);return user;}
}

动态代理（JDK 动态代理）

// InvocationHandler 实现类
public class LogInvocationHandler implements InvocationHandler {private Object target;public LogInvocationHandler(Object target) {this.target = target;}@Overridepublic Object invoke(Object proxy, Method method, Object[] args) throws Throwable {// 前置增强System.out.println("方法 " + method.getName() + " 开始执行，时间：" + LocalDateTime.now());Object result = method.invoke(target, args);// 后置增强System.out.println("方法 " + method.getName() + " 执行完成，结果：" + result);return result;}
}// 客户端使用
public class Client {public static void main(String[] args) {UserService userService = new UserServiceImpl();// 创建动态代理对象UserService proxy = (UserService) Proxy.newProxyInstance(userService.getClass().getClassLoader(),userService.getClass().getInterfaces(),new LogInvocationHandler(userService));proxy.getUserById(1L);}
}

优缺点

优点	缺点
分离核心业务与辅助功能，符合单一职责原则	静态代理扩展性差，新增接口需修改代理类
动态代理支持批量增强，灵活性高	动态代理实现复杂，调试难度大
不修改目标对象代码，符合开闭原则	增加代理层可能导致系统响应速度下降

2.2 装饰器模式（Decorator Pattern）

定义

动态地给一个对象添加一些额外的职责，比继承更灵活。

应用场景

• 功能的动态扩展（如日志增强、加密增强、数据压缩）
• 多个功能组合使用的场景（如同时添加日志和权限校验）

核心角色

• 抽象组件：定义被装饰对象的接口。
• 具体组件：实现抽象组件的原始对象。
• 装饰器：持有抽象组件的引用，提供额外功能，并调用组件的方法。

代码实现（给接口添加日志和加密装饰）

// 抽象组件
public interface DataService {String process(String data);
}// 具体组件
public class DataServiceImpl implements DataService {@Overridepublic String process(String data) {System.out.println("处理原始数据：" + data);return "processed_" + data;}
}// 装饰器抽象类
public abstract class DataDecorator implements DataService {protected DataService dataService;public DataDecorator(DataService dataService) {this.dataService = dataService;}
}// 日志装饰器
public class LogDecorator extends DataDecorator {public LogDecorator(DataService dataService) {super(dataService);}@Overridepublic String process(String data) {System.out.println("日志记录：开始处理数据，内容：" + data);String result = dataService.process(data);System.out.println("日志记录：处理完成，结果：" + result);return result;}
}// 加密装饰器
public class EncryptDecorator extends DataDecorator {public EncryptDecorator(DataService dataService) {super(dataService);}@Overridepublic String process(String data) {// 模拟加密String encryptedData = Base64.getEncoder().encodeToString(data.getBytes());System.out.println("数据加密：" + data + " -> " + encryptedData);String result = dataService.process(encryptedData);// 模拟解密（实际场景可能在返回时解密）return new String(Base64.getDecoder().decode(result.getBytes()));}
}// 客户端使用
public class Client {public static void main(String[] args) {DataService dataService = new DataServiceImpl();// 组合日志和加密装饰DataService decoratedService = new LogDecorator(new EncryptDecorator(dataService));decoratedService.process("test123");}
}

优缺点

优点	缺点
动态扩展功能，无需修改原始代码	多层装饰可能导致系统复杂度增加
支持多个功能组合，灵活性高	调试难度大，需跟踪装饰链的调用流程
避免继承带来的类爆炸问题	装饰器与组件耦合度较高，依赖抽象组件

2.3 适配器模式（Adapter Pattern）

定义

将一个类的接口转换成客户希望的另一个接口，使得原本不兼容的类可以一起工作。

应用场景

• 旧系统接口适配（如遗留系统与新系统的对接）
• 第三方组件接口适配（如不同支付接口的统一封装）
• 数据格式转换（如 JSON 与 XML 的转换）

核心角色

• 目标接口：客户端期望的接口。
• 适配者：需要被适配的原有接口。
• 适配器：实现目标接口，持有适配者的引用，将目标接口的请求转换为适配者的请求。

代码实现（支付接口适配）

// 目标接口（新系统统一支付接口）
public interface NewPayment {void pay(String userId, BigDecimal amount);
}// 适配者（旧系统支付宝接口）
public class OldAlipay {public void doPay(String userAccount, double money) {System.out.println("旧系统支付宝支付：用户" + userAccount + "，金额" + money + "元");}
}// 适配器
public class AlipayAdapter implements NewPayment {private OldAlipay oldAlipay;public AlipayAdapter(OldAlipay oldAlipay) {this.oldAlipay = oldAlipay;}@Overridepublic void pay(String userId, BigDecimal amount) {// 转换参数并调用旧接口oldAlipay.doPay(userId, amount.doubleValue());}
}// 客户端使用
public class Client {public static void main(String[] args) {NewPayment payment = new AlipayAdapter(new OldAlipay());payment.pay("funian", new BigDecimal("100"));}
}

优缺点

优点	缺点
解决接口不兼容问题，复用现有代码	增加系统复杂度，引入适配器层
无需修改原有代码，符合开闭原则	适配器可能需要处理复杂的参数转换逻辑
提高代码复用性和灵活性	过多的适配器可能导致系统难以维护

三、行为型设计模式

行为型模式关注对象间的交互行为，通过定义对象间的通信规则，提升代码的可扩展性和可维护性。后端开发中常用的行为型模式包括策略模式、观察者模式、模板方法模式、责任链模式和命令模式。

3.1 策略模式（Strategy Pattern）

定义

定义一系列算法，将每个算法封装起来，并使它们可以相互替换，让算法的变化不影响使用算法的客户。

应用场景

• 多种算法可选的场景（如排序算法、加密算法）
• 业务规则动态切换（如折扣策略、计费策略）
• 复杂条件判断的优化（用策略替换 if-else 或 switch）

核心角色

• 策略接口：定义算法的统一方法。
• 具体策略：实现策略接口的具体算法。
• 上下文：持有策略接口的引用，负责调用策略。

代码实现（订单折扣策略）

// 策略接口
public interface DiscountStrategy {BigDecimal calculateDiscount(BigDecimal amount);
}// 具体策略：新用户折扣（9折）
public class NewUserDiscount implements DiscountStrategy {@Overridepublic BigDecimal calculateDiscount(BigDecimal amount) {return amount.multiply(new BigDecimal("0.9"));}
}// 具体策略：会员折扣（8折）
public class MemberDiscount implements DiscountStrategy {@Overridepublic BigDecimal calculateDiscount(BigDecimal amount) {return amount.multiply(new BigDecimal("0.8"));}
}// 上下文
public class OrderContext {private DiscountStrategy discountStrategy;// 动态设置策略public void setDiscountStrategy(DiscountStrategy discountStrategy) {this.discountStrategy = discountStrategy;}// 计算最终金额public BigDecimal calculateFinalAmount(BigDecimal amount) {if (discountStrategy == null) {return amount; // 无折扣}return discountStrategy.calculateDiscount(amount);}
}// 客户端使用
public class Client {public static void main(String[] args) {OrderContext context = new OrderContext();BigDecimal amount = new BigDecimal("1000");// 新用户折扣context.setDiscountStrategy(new NewUserDiscount());System.out.println("新用户最终金额：" + context.calculateFinalAmount(amount));// 会员折扣context.setDiscountStrategy(new MemberDiscount());System.out.println("会员最终金额：" + context.calculateFinalAmount(amount));}
}

优缺点

优点	缺点
分离算法定义与使用，符合单一职责原则	增加系统类的数量，每个策略对应一个类
支持算法动态切换，灵活性高	客户端需了解所有策略，增加使用成本
避免复杂的条件判断语句	策略间若有依赖，维护难度增加

3.2 观察者模式（Observer Pattern）

定义

定义对象间的一种一对多依赖关系，当一个对象的状态发生变化时，所有依赖它的对象都会得到通知并自动更新。

应用场景

• 事件通知机制（如消息订阅、状态变更通知）
• 发布-订阅系统（如 MQ 消息队列的发布订阅模式）
• 监控系统（如服务状态监控、日志告警）

核心角色

• 主题（Subject）：被观察的对象，维护观察者列表，提供注册、移除和通知方法。
• 观察者（Observer）：接收主题通知并进行更新操作。

代码实现（订单状态通知）

// 观察者接口
public interface Observer {void update(Order order);
}// 具体观察者：短信通知
public class SmsObserver implements Observer {@Overridepublic void update(Order order) {System.out.println("短信通知：订单" + order.getOrderId() + "状态变更为" + order.getStatus());}
}// 具体观察者：邮件通知
public class EmailObserver implements Observer {@Overridepublic void update(Order order) {System.out.println("邮件通知：订单" + order.getOrderId() + "状态变更为" + order.getStatus());}
}// 主题
public class OrderSubject {private List<Observer> observers = new ArrayList<>();// 注册观察者public void registerObserver(Observer observer) {observers.add(observer);}// 移除观察者public void removeObserver(Observer observer) {observers.remove(observer);}// 通知所有观察者public void notifyObservers(Order order) {for (Observer observer : observers) {observer.update(order);}}
}// 订单实体
@Data
public class Order {private Long orderId;private String status;public Order(Long orderId, String status) {this.orderId = orderId;this.status = status;}// 状态变更时通知观察者public void setStatus(String status) {this.status = status;new OrderSubject().notifyObservers(this);}
}// 客户端使用
public class Client {public static void main(String[] args) {OrderSubject subject = new OrderSubject();subject.registerObserver(new SmsObserver());subject.registerObserver(new EmailObserver());Order order = new Order(1001L, "待支付");order.setStatus("已支付"); // 状态变更，触发通知}
}

优缺点

优点	缺点
解耦主题与观察者，支持动态添加/移除观察者	观察者过多时，通知效率可能下降
支持一对多的广播通知	观察者与主题间可能存在循环依赖
符合开闭原则，新增观察者无需修改主题代码	通知顺序不确定，可能影响业务逻辑

3.3 模板方法模式（Template Method Pattern）

定义

定义一个操作中的算法骨架，将某些步骤延迟到子类中，使得子类可以不改变算法的结构即可重定义该算法的某些特定步骤。

应用场景

• 具有固定流程的业务逻辑（如数据导入、接口调用、任务执行）
• 多个子类共享相同算法骨架的场景（如基础 CRUD 操作）

核心角色

• 抽象父类：定义算法骨架，包含抽象方法（子类实现）和具体方法（固定步骤）。
• 具体子类：实现抽象父类的抽象方法，定制算法的特定步骤。

代码实现（数据导入模板）

// 抽象父类
public abstract class DataImportTemplate {// 模板方法：定义算法骨架public final void importData(String filePath) {// 固定步骤1：读取文件String data = readFile(filePath);// 固定步骤2：验证数据if (validateData(data)) {// 可变步骤：解析数据（子类实现）List<Object> parsedData = parseData(data);// 可变步骤：保存数据（子类实现）saveData(parsedData);// 固定步骤3：记录日志logImportSuccess(filePath);} else {logImportFailure(filePath, "数据验证失败");}}// 固定方法：读取文件private String readFile(String filePath) {System.out.println("读取文件：" + filePath);return "模拟文件数据";}// 固定方法：验证数据private boolean validateData(String data) {System.out.println("验证数据：" + data);return !data.isEmpty();}// 抽象方法：解析数据（子类实现）protected abstract List<Object> parseData(String data);// 抽象方法：保存数据（子类实现）protected abstract void saveData(List<Object> data);// 固定方法：记录成功日志private void logImportSuccess(String filePath) {System.out.println("文件" + filePath + "导入成功");}// 固定方法：记录失败日志private void logImportFailure(String filePath, String reason) {System.out.println("文件" + filePath + "导入失败，原因：" + reason);}
}// 具体子类：CSV 数据导入
public class CsvDataImport extends DataImportTemplate {@Overrideprotected List<Object> parseData(String data) {System.out.println("解析 CSV 数据：" + data);return Collections.singletonList("csv_parsed_data");}@Overrideprotected void saveData(List<Object> data) {System.out.println("保存 CSV 数据：" + data);}
}// 客户端使用
public class Client {public static void main(String[] args) {DataImportTemplate importTemplate = new CsvDataImport();importTemplate.importData("test.csv");}
}

优缺点

优点	缺点
统一算法骨架，复用固定步骤代码	子类过多时，系统复杂度增加
子类专注于实现特定步骤，符合单一职责原则	算法骨架修改困难，需修改抽象父类（违反开闭原则）
便于扩展，新增业务只需新增子类	抽象父类与子类耦合度较高

四、设计模式在后端框架中的应用

4.1 Spring 框架中的设计模式

• 单例模式：Spring 容器中的 Bean 默认是单例模式（通过 singleton 作用域实现）。
• 工厂模式：Spring 的 BeanFactory 和 ApplicationContext 是工厂模式的典型应用，负责创建和管理 Bean。
• 代理模式：Spring AOP 基于动态代理实现（JDK 动态代理或 CGLIB 代理），用于日志、事务等增强功能。
• 模板方法模式：JdbcTemplate、RestTemplate 等模板类，封装固定流程，暴露可变步骤给用户。

4.2 MyBatis 框架中的设计模式

• 工厂模式：SqlSessionFactory 用于创建 SqlSession 实例。
• 代理模式：Mapper 接口的实现通过动态代理生成，将接口方法映射为 SQL 语句。
• 策略模式：Executor 接口的不同实现（如 SimpleExecutor、BatchExecutor）对应不同的执行策略。

五、设计模式选择原则与注意事项

5.1 选择原则

1. 按需使用：不盲目追求设计模式，简单业务场景优先使用简洁代码。
2. 符合设计原则：优先遵循单一职责、开闭原则、依赖倒置等核心设计原则。
3. 考虑扩展性：未来可能变化的业务逻辑，优先选择灵活性高的设计模式（如策略模式、装饰器模式）。
4. 团队共识：选择团队熟悉的设计模式，避免过度设计导致维护成本增加。

5.2 注意事项

1. 避免过度设计：简单场景使用复杂设计模式会增加系统复杂度。
2. 平衡灵活性与性能：部分设计模式（如代理、装饰器）会引入额外开销，需在性能敏感场景谨慎使用。
3. 结合框架特性：充分利用现有框架提供的设计模式实现，避免重复造轮子。
4. 关注业务本质：设计模式是工具，最终需服务于业务需求，而非为了使用模式而使用。

六、总结

设计模式是后端开发中的重要技术积累，掌握常用设计模式能帮助开发者更高效地解决复杂业务问题，提升代码质量。本文介绍的创建型、结构型、行为型三大类设计模式，覆盖了后端开发中最常见的场景，通过具体代码示例和场景分析，希望能帮助开发者理解并灵活运用。

在实际开发中，需结合业务需求、团队技术栈和系统扩展性综合选择设计模式，避免生搬硬套。同时，关注主流框架中设计模式的应用实践，能进一步加深对设计模式的理解，提升技术架构能力。

参考资料

1. 《设计模式》