为什么需要设计模式？

1. 从"烂代码"说起

// 烂代码：大量 if-else
public void pay(String type, BigDecimal amount) {
    if ("alipay".equals(type)) {
        // 支付宝逻辑 50 行
    } else if ("wechat".equals(type)) {
        // 微信逻辑 50 行
    } else if ("bank".equals(type)) {
        // 银行卡逻辑 50 行
    }
    // 每次新增支付方式都要改这个方法...
}

问题不在 if-else 本身，而在于新增支付方式会持续迫使 pay 方法反复修改，对扩展不够封闭。分支少、逻辑简单且很少变化时，直接写条件分支反而更清晰；当支付方式持续增加、各分支逻辑独立且复杂时，则可以把支付行为封装为策略。是否值得引入，还要看变化频率、分支复杂度和抽象成本。具体重构过程和适用边界见策略模式与重构到设计模式。

2. 设计模式是什么

前人总结的针对反复出现的设计问题给出的可复用方案。

不是发明，是发现。它描述问题出现的条件、参与对象及其协作关系，而不是可直接套用的固定代码。

3. 学设计模式，最终学什么

• 识别反复出现的设计问题，以及它们为什么会出现。
• 理解模式如何分配职责、组织依赖、隔离变化。
• 根据复杂度、扩展需求与维护成本，判断是否该引入某个模式，以及何时不该引入。

4. 怎么学不枯燥

每个模式我会用这个结构讲：

1. 🏠 生活类比 — 30 秒讲明白
2. 💩 烂代码 — 问题在哪
3. ✨ 模式方案 — 怎么改
4. 💻 代码实现 — 可运行
5. 🔧 框架应用 — Spring/JDK 中的真实例子
6. ⚠️ 适用场景 — 什么时候用、什么时候不用