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

你每用一个设计模式，可能就多了一个过度设计

news 2026/6/13 8:53:42

设计模式教程看多了，容易得一种病：看什么代码都觉得需要重构，重构就想套模式。结果一个 CRUD 接口搞出五个类三个接口，新人接手代码先看半小时类图才能找到入口。

我见过最离谱的案例：一个内部工具的配置模块，总共 3 个配置项，被人用策略模式 + 工厂模式 + 模板方法模式重构了一遍。重构前一个 switch 搞定，重构后 8 个类 2 个接口。说是"开闭原则"，结果 3 个月里需求没变过一次，但每次加配置项要改 4 个文件。

今天不聊怎么用设计模式，聊聊什么时候不该用。

单例模式的温床：全局变量披着面向对象的外衣

单例模式是最容易被滥用的模式，因为它的卖点是"全局唯一"，这跟全局变量的卖点一模一样。

```java // 这种单例跟全局变量有什么区别？ public class AppContext { private static AppContext instance = new AppContext();

private Map<String, Object> attributes = new HashMap<>(); public static AppContext getInstance() { return instance; } public void setAttribute(String key, Object value) { attributes.put(key, value); } public Object getAttribute(String key) { return attributes.get(key); }

} ```

这不是单例模式，这是HashMap换了件衣服。但它比HashMap更危险，因为单例模式给了你一种"我做了设计"的错觉。

单例真正需要用的场景很少：连接池、线程池、全局配置。如果你的单例只是个数据袋（data bag），大概率不需要单例，需要的是重新审视你的依赖关系。

更糟糕的是单例 + 可变状态。一个有状态的 Singleton 在测试中是噩梦——你不能隔离测试，因为状态是全局的，上一个测试用例修改的状态会影响下一个。

工厂模式的接口爆炸

工厂模式的问题是：每加一个产品，要加一个实现类。这在产品类型多的时候没问题，但产品类型少的时候就是负担。

```java // 只有两个通知渠道，用工厂模式值得吗？ public interface NotificationSender { void send(String message, String recipient); }

public class EmailSender implements NotificationSender { ... } public class SmsSender implements NotificationSender { ... }

public class NotificationSenderFactory { public NotificationSender create(String type) { switch (type) { case "email": return new EmailSender(); case "sms": return new SmsSender(); default: throw new IllegalArgumentException(); } } } ```

3 个接口/类 + 1 个工厂类 = 4 个文件，处理 2 个渠道。直接写两个 Service 类 + 一个 if-else 是 2 个文件。

你可能会说"以后会加渠道"。但问题是：你确定以后会加吗？很多项目的"以后会加"永远没来，但工厂的维护成本从第一天就开始了。

我的判断标准：少于 3 个实现类的接口，不要急着建工厂。等第 3 个实现类真的出现的时候再重构，成本很低。

策略模式只有 2 个策略时的尴尬

策略模式的卖点是用组合替代继承，避免 if-else 膨胀。但如果只有 2 个策略，效果适得其反：

```java // 只有两个策略 public interface DiscountStrategy { BigDecimal calculate(BigDecimal price); }

public class NormalDiscount implements DiscountStrategy { public BigDecimal calculate(BigDecimal price) { return price.multiply(new BigDecimal("0.9")); } }

public class VipDiscount implements DiscountStrategy { public BigDecimal calculate(BigDecimal price) { return price.multiply(new BigDecimal("0.8")); } }

// 使用方 DiscountStrategy strategy = isVip ? new VipDiscount() : new NormalDiscount(); strategy.calculate(price); ```

对比直接写：

java BigDecimal finalPrice = isVip ? price.multiply(new BigDecimal("0.8")) : price.multiply(new BigDecimal("0.9"));

策略模式的版本多了一个接口、两个实现类，使用方的代码也没少多少（还是有个三元表达式）。如果策略逻辑只有一行，模式带来的复杂度已经超过了它解决的问题。

策略模式的收益跟策略数量正相关。2 个策略时收益约等于 0，3-4 个时开始值得，5 个以上时明显赚。别在 2 个策略的时候就急着上模式。

观察者模式的调试地狱

观察者模式的坑在调试的时候才会暴露。你断点打在业务方法上，发现某个状态不对，但不知道是谁改的——因为 Observer 链里有 5 个监听器，每个都可能触发状态变更。

java // 看着很优雅，调试的时候想骂人 eventBus.register(new OrderCreatedListener()); // 监听订单创建 eventBus.register(new InventoryUpdateListener()); // 更新库存 eventBus.register(new PointsUpdateListener()); // 更新积分 eventBus.register(new NotificationListener()); // 发通知 eventBus.register(new AnalyticsListener()); // 数据统计

5 个监听器，5 个类，可能分布在 5 个包里。一个eventBus.post(orderCreatedEvent)调用下去，你要跳 5 次才能跟完整个链路。更惨的是，如果其中一个监听器又 post 了新事件，整个调用链变成了一棵树。

我的做法：观察者链路超过 3 层就必须画时序图。不是因为文档需要，是因为你自己也会忘。

另外，观察者模式的异常处理是个大坑：如果 Listener3 抛异常了，Listener4 和 Listener5 还要不要执行？如果执行，状态可能不一致；如果不执行，一个无关的监听器故障会阻塞整个事件链。

Guava EventBus 的做法是：每个监听器独立 try-catch，互不影响。但这也意味着一个监听器的异常不会被上层感知到。如果你需要"任何一个监听器失败都回滚"的语义，EventBus 做不到，得用别的方式。

真实案例：过度设计→回归简单

之前接手过一个项目的权限模块，前任开发者做了这样的设计：

PermissionChecker（策略模式）→ 4 个策略实现
PermissionProvider（工厂模式）→ 2 个工厂
PermissionEvent（观察者模式）→ 3 个监听器
PermissionCache（装饰器模式）→ 2 个装饰器

总共 15 个类文件。权限规则呢？就一条：管理员全部放行，其他用户按角色判断。

重构后：

java public class PermissionService { public boolean check(String userId, String resource) { if (isAdmin(userId)) return true; return roleMapper.hasPermission(userId, resource); } }

1 个类，1 个方法。原来 15 个类干的事情，1 个类全干完了。

前任开发者不是能力不行，他是被设计模式洗脑了——觉得不用模式就不算设计。但设计的目标是解决问题，不是展示模式。