Java 设计模式学习路线：原则、分类与使用规范

学习设计模式，最容易走偏的方式是背类图、背名称、背面试答案。更有效的方式，是先理解设计原则，再看模式解决了哪类变化问题。

设计模式不是为了让代码看起来“高级”，而是为了在变化出现时，让代码少改一点、影响面小一点、协作关系清楚一点。

设计模式解决什么问题

设计模式本质上是在处理三件事：

• 对象怎么创建。
• 对象怎么组合。
• 对象之间的职责怎么流转。

所以经典设计模式通常分成三类：

分类	关注点	典型模式
创建型	对象创建过程	单例、工厂、原型、建造者
结构型	对象组合关系	适配器、桥接、装饰者、组合、外观、享元、代理
行为型	对象协作和职责流转	模板方法、命令、访问者、迭代器、观察者、中介者、备忘录、解释器、状态、策略、职责链

这三类模式对应的不是固定代码模板，而是三类设计问题。

七大设计原则

在使用设计模式前，先要理解七大原则。

单一职责原则

一个类只负责一类职责。判断标准不是“类有几个方法”，而是“类有几个变化原因”。

如果一个类既负责解析文件，又负责保存数据库，还负责发送通知，那么它会因为三种原因发生变化。这时应该拆分职责。

接口隔离原则

客户端不应该依赖自己不需要的方法。

如果一个接口很大，实现类被迫实现大量空方法，说明接口边界太粗。更好的做法是拆成多个小接口，让调用方只依赖自己需要的能力。

依赖倒转原则

高层模块不应该依赖低层实现，二者都应该依赖抽象。

项目里常见的做法是使用接口、抽象类、构造器注入，把具体实现放到边缘位置。

public interface MessageSender {
    void send(String message);
}

public class OrderService {
    private final MessageSender sender;

    public OrderService(MessageSender sender) {
        this.sender = sender;
    }

    public void createOrder() {
        sender.send("order created");
    }
}

OrderService 不关心消息是短信、邮件还是站内信，这样后续替换实现时不会影响订单主流程。

里氏替换原则

子类应该能替换父类，并且不破坏原有行为。

很多继承问题不是语法错误，而是语义错误。例如父类约定某个方法一定成功，子类却在某些场景直接抛异常，这就会破坏调用方预期。

开闭原则

对扩展开放，对修改关闭。

这是设计模式里最核心的原则之一。模式的目的通常不是“完全不改代码”，而是把变化集中到扩展点上，避免修改稳定主流程。

迪米特法则

一个对象应该尽量少了解其他对象。

如果 A 调用 B，B 再暴露 C，A 又直接操作 C，依赖链就会越来越长。更好的做法是让 B 提供明确方法，隐藏内部协作对象。

合成复用原则

优先使用组合，而不是继承。

继承会把父类细节暴露给子类，层级深了之后很难维护。组合更灵活，可以在运行期替换组件，也更符合依赖倒转。

使用设计模式的规范

设计模式不能滥用。项目中使用模式前，建议先做四个判断。

1. 先确认变化点

如果没有明确变化点，不要为了模式而模式。

例如只有一种支付方式时，不一定要立刻上策略模式；但如果产品明确规划微信、支付宝、银行卡、余额支付，那么策略模式就有价值。

2. 先抽象职责，再写类图

不要先想“我要用哪个模式”，而是先问：

• 谁是稳定的？
• 谁是变化的？
• 谁负责创建？
• 谁负责调度？
• 谁负责扩展？

模式应该服务于职责拆分。

3. 保持命名清楚

设计模式最容易带来抽象膨胀。命名必须让业务含义清楚。

不要只叫 Context、Handler、Strategy，而应该结合业务：

PaymentContext
OrderApprovalHandler
DiscountStrategy

模式名可以体现在结构里，但业务语义必须放在第一位。

4. 控制抽象层数

设计模式通常会增加类数量。小项目或简单逻辑里，过度模式化会降低可读性。

比较好的标准是：当新增一个变化点时，如果原代码需要改很多地方，才考虑引入模式。

常见误区

误区一：把设计模式当模板

设计模式不是固定代码片段。不同业务场景里，同一个模式会有不同形态。

误区二：为了开闭原则无限抽象

开闭原则不是要求所有地方都可扩展，而是要求稳定主流程不要频繁被修改。

误区三：只看类图，不看对象生命周期

创建型模式尤其要关注对象生命周期。例如单例适合无状态或全局共享对象，不适合保存用户上下文。

误区四：忽略测试

引入模式后，测试应该覆盖扩展点。例如策略模式要测试不同策略，职责链要测试链路中断和继续传递。

小结

设计模式学习顺序建议是：

1. 先掌握七大原则。
2. 再理解创建型、结构型、行为型三类问题。
3. 最后结合业务场景判断是否需要模式。

真正有用的设计模式，不是让类变多，而是让变化变得可控。