当前位置：首页 > news >正文

# 设计模式常考类型详解

news 2026/6/3 21:42:04

设计模式是软件开发过程中经过反复验证的、针对特定场景下常见问题的通用解决方案。它不是语法规则，而是提升代码可复用性、可维护性和可扩展性的实践经验总结。根据功能定位，设计模式通常分为创建型模式、结构型模式和行为型模式三大类，本次聚焦面试与考试中最常出现的5种核心模式展开分析。

核心定义：确保一个类在整个程序运行周期中仅存在一个实例，并提供一个全局访问该实例的统一入口。

实现要点：
1. 将类的构造函数私有化，禁止外部通过new关键字直接创建实例
2. 类内部维护一个静态私有变量存储唯一实例
3. 提供一个公开的静态方法，用于获取该唯一实例（首次调用时初始化实例，后续调用直接返回已有实例）
典型应用场景：
- 系统配置管理类：避免多实例导致的配置不一致问题
- 日志记录器：统一日志写入入口，防止多实例同时写文件冲突
- 数据库连接池：控制连接数量，避免资源过度占用

常见实现方式对比：

核心定义：定义一个创建对象的抽象工厂接口，让子类决定实例化哪一个具体产品类，将对象的实例化延迟到子类中完成。

核心角色：
1. 抽象产品：定义产品的公共接口
2. 具体产品：实现抽象产品接口的具体类
3. 抽象工厂：声明创建产品的抽象方法
4. 具体工厂：实现抽象工厂方法，返回具体产品实例
典型应用场景：
- 支付网关对接：不同支付渠道（微信、支付宝、银联）对应不同的支付处理器，通过工厂方法动态创建对应实现
- 日志框架适配：支持无缝切换Log4j、Slf4j等不同日志实现
- 导出工具开发：根据导出格式（Excel、PDF、CSV）创建对应的导出处理器
优势：
- 符合开闭原则：新增产品时只需新增对应工厂类，无需修改已有代码
- 解耦对象创建与使用：调用方无需关心对象创建细节，仅需依赖抽象接口

核心定义：将一个类的接口转换成客户端期望的另一个接口，解决接口不兼容导致无法协同工作的问题。

分类：
1. 类适配器：通过继承适配者类实现适配（单继承限制适用场景）
2. 对象适配器：通过组合适配者对象实现适配（更灵活，推荐使用）
典型应用场景：
- 第三方SDK集成：原有系统接口与第三方接口定义不一致时，通过适配器做转换层
- 旧系统升级：新系统需要复用旧系统的功能，但接口不匹配的场景
- 不同数据格式转换：例如将第三方返回的XML格式数据转换为系统内部使用的JSON格式
与装饰器模式的区别：
适配器模式的核心是接口转换，目的是让不兼容的接口可以协同工作；装饰器模式的核心是增强原有功能，不改变原有接口，仅在原有能力基础上附加新特性。

核心定义：定义对象间一对多的依赖关系，当一个对象（主题/被观察者）的状态发生改变时，所有依赖它的对象（观察者）都会收到通知并自动更新。

核心角色：
1. 主题（Subject）：维护观察者列表，提供注册、移除观察者和通知所有观察者的方法
2. 观察者（Observer）：定义更新接口，在收到主题通知时执行相应操作
典型应用场景：
- 消息通知系统：用户关注的内容更新后，主动推送通知给所有关注用户
- 事件监听机制：GUI框架中的按钮点击事件监听、Spring框架中的事件驱动模型
- 数据同步：例如商品库存更新后，同步通知购物车、订单、促销等相关模块
优势与注意事项：
优势：实现了主题与观察者之间的解耦，支持动态添加和删除观察者
注意事项：当观察者数量过多时，通知过程可能耗时较长；需避免循环依赖导致的系统崩溃。

核心定义：定义一系列算法，将每个算法分别封装起来，让它们之间可以互相替换，算法的变化独立于使用算法的客户端。

核心角色：
1. 抽象策略：定义所有支持算法的公共接口
2. 具体策略：实现抽象策略接口，封装具体的算法逻辑
3. 上下文（Context）：持有策略对象的引用，提供给客户端调用的接口
典型应用场景：
- 支付方式选择：不同支付方式（余额支付、银行卡支付、花呗支付）对应不同的计算逻辑，可封装为不同策略
- 排序算法选择：根据数据规模、排序要求动态选择快速排序、冒泡排序或归并排序
- 优惠活动计算：不同促销活动（满减、折扣、优惠券）对应不同的优惠计算规则
优势：
- 避免使用大量条件判断语句（if-else/switch）
- 算法可以独立演化和扩展，客户端无需感知变化
- 运行时可以动态切换算法实现