1. 浮灯记首页
  2. 编程
  3. java

Java设计模式滥用反思：何时该引入，何时该重构

• java • 阅读 3

从“模式崇拜”到“模式负担”

很多团队在经历过“设计模式是优秀程序员标志”的阶段后，会进入另一个困境：代码里到处是模式，但维护成本不降反增。一个简单的配置读取被包装成三层抽象工厂，一个本应是普通工具类的对象被强行做成单例，导致单元测试难以隔离。问题不在于模式本身，而在于我们混淆了“工具”和“目的”。设计模式的核心价值是应对变化和提升可维护性，但当模式的应用本身变成了变化的阻碍时，就需要重新审视了。

Java设计模式滥用反思：何时该引入，何时该重构

单例模式：全局唯一还是画地为牢？

单例模式大概是滥用排行榜的第一名。它的初衷是管理全局唯一的资源，比如数据库连接池、日志管理器或运行时环境。但在很多代码里，它成了“懒得管理对象生命周期”的借口。

一个典型的滥用场景是，将某个业务服务类（比如OrderService）设计成单例，仅仅因为“觉得它只需要一个实例”。这忽略了服务类可能依赖有状态的DAO或外部客户端，单例化会让这些依赖在整个应用生命周期内无法刷新，也严重阻碍了单元测试——你无法为每个测试用例注入不同的Mock依赖。

// 滥用示例：业务服务强行单例化
public class OrderService {
    private static OrderService instance;
    private OrderDao orderDao; // 依赖难以替换

    private OrderService() {
        this.orderDao = new OrderDao(); // 紧耦合，无法Mock
    }

    public static synchronized OrderService getInstance() {
        if (instance == null) {
            instance = new OrderService();
        }
        return instance;
    }
    // ... 业务方法
}

该用单例的时候：对象确实是全局唯一且无状态的，或者其状态是应用级共享且线程安全的。例如，工具类（如果确实无状态）、缓存管理器、配置信息的只读访问点。Spring的@Service默认单例是合理的，因为容器管理了其依赖注入和代理，与手写单例有本质区别。

该删单例的时候：当你发现这个类需要被测试、需要支持多套配置、或者其“唯一性”只是当前假设时。改用依赖注入，让容器或工厂来管理实例生命周期，代码会灵活得多。

工厂模式：解耦还是制造复杂度？

工厂模式的本意是将对象创建逻辑封装起来，让客户端代码与具体类解耦。但过度使用工厂，尤其是多层抽象的工厂，会让简单创建过程变得难以追踪。

想象一个场景：系统需要根据文件后缀名选择不同的解析器。初期只有两三种格式，一个简单的if-else或Map<String, Parser>就能清晰解决。但有些开发者会提前引入“抽象工厂+具体工厂+产品族”的完整架构，美其名曰“为未来扩展做准备”。结果就是，每新增一个解析器，需要修改或新增多个类，阅读代码需要跳转四五层，维护成本远高于那几行if-else。

场景 简单方案 工厂模式方案 取舍建议
2-3种固定类型，变化极少 if-else 或 switch 简单静态工厂方法 用简单方案，避免过度设计
类型经常增加，且创建逻辑复杂 维护困难，易出错 工厂方法模式（接口+实现） 引入工厂，将变化封装在一处
需要创建一组相关联的对象 难以保证对象间的搭配 抽象工厂模式 使用抽象工厂管理产品族
运行时动态注册类型（如插件） 几乎无法实现 工厂 + 注册表 (Map) 必须用工厂，配合服务发现机制

该用工厂的时候：对象创建逻辑确实复杂（涉及组装、配置），或者具体类型需要在运行时动态决定（如插件化系统），或者你需要统一管理对象创建前后的逻辑（如缓存、代理）。Spring的BeanFactory、MyBatis的SqlSessionFactory都是正面案例。

该删或简化工厂的时候：当创建逻辑只是一次简单的new，且未来也不太可能变化时。直接new的代码是最直白、最易读的。如果只是为了“不用new”而套一层工厂，那是本末倒置。

策略与模板方法：灵活性的代价

行为型模式如策略模式和模板方法模式，能优雅地封装算法族和固定流程。滥用它们，则会产生大量细碎的类，让系统显得“架构过度”。

我曾见过一个促销系统，为三种折扣方式（直减、满减、折扣）定义了策略接口，这很合理。但后来为每种策略又配了一个工厂，为工厂配了一个缓存代理，为缓存代理配了一个门面……最终，修改一个折扣公式，需要穿越七八个类。这就是典型的“模式驱动开发”，而非“问题驱动开发”。

判断行为型模式是否滥用的一个关键信号是：这些策略或模板是否真的会独立变化？如果两个算法总是同时修改，或者某个步骤永远只有一个实现，那么强行拆开它们，就是用模式制造了不必要的间接层。

重构的时机：识别模式坏味道

  • 测试困难：因为某个类是单例，导致其依赖无法在测试中被Mock或替换。
  • 修改扩散：添加一个简单功能，需要修改一个模式涉及的多个类（如抽象工厂的所有子类）。
  • 理解成本高：新同事需要花半天时间才能理清一个简单对象的创建流程，因为中间隔着装饰器、代理、工厂等多层包装。
  • 模式嵌套过深：代码中出现“工厂的工厂”、“装饰器的装饰器”，而业务复杂度并未达到相应级别。

务实的原则：从场景出发，而非从模式出发

1. 延迟决策：不要为“可能”会有的变化提前引入复杂模式。等变化第一次真正发生时再重构，你会对“如何变”有更准确的认识。

2. 衡量复杂度：对比引入模式带来的解耦收益，与增加的代码结构复杂度。如果收益不明显，优先使用更简单的方案。

3. 依赖注入优先：对于实例管理，现代开发中应优先考虑依赖注入容器（如Spring）。它本身就提供了单例、原型等多种作用域管理，比你手写模式更标准、更可测试。

4. 定期重构：代码在演进。初期合理的简单设计，在业务复杂后可能就需要引入模式；初期引入的过度设计，在业务稳定后也可能需要简化。把代码结构调整视为持续的过程。

说到底，设计模式是优秀工程师总结出来的地图，而不是必须抵达的目的地。看到代码中的模式滥用时，勇敢地删改和简化，让代码重新服务于业务逻辑的清晰表达，这才是对设计模式精神更深刻的理解。

原创文章，作者：，如若转载，请注明出处：https://fudengji.cn/article/71/

赞 (0)
上一篇 2026年7月30日 下午10:59
下一篇 2026年7月30日 下午11:01

相关推荐