写了8年Java后，我总结了这5个最常用的设计模式场景如果你还在为“设计模式太抽象”而头疼，不妨看看这篇。我将结合自己8

写了8年Java后，我总结了这5个最常用的设计模式场景

写在前面：
如果你还在为“设计模式太抽象”而头疼，不妨看看这篇。我将结合自己8年Java开发经验，分享我在真实业务中用过的设计模式，以及它们是如何在项目中“润物细无声”地解决问题的。

☕ 一句话总结设计模式的本质

设计模式不是套路，而是一种表达思想的方式。
就像诗人写诗用韵律，我们写代码用模式。

🧭 真实开发中，我遇到的问题

在我参与的几个中后台系统中，常常会遇到这些问题：

业务逻辑分支越来越复杂
新需求总要改一堆代码
Controller 层肥得像个胖子
if-else 嵌套像俄罗斯套娃
新人接手系统要摸索一周

于是，我逐渐意识到 —— 设计模式不是用来背的，是用来救命的。

✅ 常见设计模式实战场景

我挑了几个印象最深的、应用最频繁的设计模式来分享。

1. 策略模式（Strategy Pattern）

📌 场景：多种业务策略切换，避免 if-else 地狱

业务背景：
做过订单系统的都知道，优惠计算、运费计算、积分抵扣，都是“策略型”的问题。

常见错误写法：

if ("COUPON".equals(type)) {
    // 优惠券逻辑
} else if ("FULL_REDUCTION".equals(type)) {
    // 满减逻辑
} else if ("VIP".equals(type)) {
    // VIP 折扣逻辑
}

策略模式优化：

public interface DiscountStrategy {
    BigDecimal calculate(Order order);
}

@Component("COUPON")
public class CouponDiscount implements DiscountStrategy {
    public BigDecimal calculate(Order order) {
        // ...
    }
}

@Component("VIP")
public class VipDiscount implements DiscountStrategy {
    public BigDecimal calculate(Order order) {
        // ...
    }
}

@Service
public class DiscountService {
    @Autowired
    private Map<String, DiscountStrategy> strategyMap;

    public BigDecimal discount(String type, Order order) {
        return strategyMap.get(type).calculate(order);
    }
}

收益：

新增策略无需动原有逻辑

逻辑更清晰，便于扩展

遵循开闭原则

2. 工厂模式（Factory Pattern）

📌 场景：根据配置动态创建不同类型的对象

业务背景：
比如你做一个消息推送系统，支持短信、微信、钉钉等多种渠道。

工厂模式应用：

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

public class SmsSender implements MessageSender { ... }
public class DingTalkSender implements MessageSender { ... }

public class MessageSenderFactory {
    public static MessageSender getSender(String channel) {
        switch (channel) {
            case "SMS": return new SmsSender();
            case "DING": return new DingTalkSender();
            default: throw new IllegalArgumentException("不支持的渠道");
        }
    }
}

进阶：
可以结合 Spring + 工厂 + 反射 + 配置驱动，做到“无代码接入新渠道”。

3. 责任链模式（Chain of Responsibility）

📌 场景：审批流、过滤器、表单校验流

业务背景：
一个请假申请，可能要经过部门主管 → HR → 总监审批，不同条件走不同流程。

责任链模式实现示意：

public abstract class Approver {
    protected Approver next;
    public void setNext(Approver next) { this.next = next; }
    public abstract void process(Request request);
}

public class Manager extends Approver {
    public void process(Request request) {
        if (request.getDays() <= 3) {
            // 批准
        } else if (next != null) {
            next.process(request);
        }
    }
}

好处：

责任明确，流程清晰

易于插拔处理节点

4. 观察者模式（Observer Pattern）

📌 场景：事件驱动、消息推送、用户订阅

业务背景：
用户下单后，我们可能需要：

发短信
发邮件
增加积分
发送站内通知

用观察者模式可以优雅解耦：

public class OrderEvent extends ApplicationEvent {
    private Order order;
    // ...
}

@Component
public class SmsObserver implements ApplicationListener<OrderEvent> {
    public void onApplicationEvent(OrderEvent event) {
        // 发送短信
    }
}

优雅之处：

低耦合，易扩展

Spring 自带事件发布机制

5. 装饰者模式（Decorator Pattern）

📌 场景：增强功能、动态扩展类的行为

业务背景：
比如你在做一个文件上传功能，需要在原有上传上增加“加密”、“压缩”、“日志记录”等功能。

装饰者模式巧妙应用：

public interface FileUploader {
    void upload(File file);
}

public class BasicUploader implements FileUploader {
    public void upload(File file) {
        // 上传逻辑
    }
}

public class EncryptUploader implements FileUploader {
    private FileUploader delegate;
    public EncryptUploader(FileUploader delegate) {
        this.delegate = delegate;
    }
    public void upload(File file) {
        // 加密
        delegate.upload(file);
    }
}

🧠 思维总结：如何判断该用设计模式？

三问法则：

if-else 太多了？ → 想想策略模式
逻辑耦合太紧？ → 想想观察者 or 责任链
扩展成本太高？ → 想想工厂 or 装饰者

🚀 写在最后：设计模式不是银弹，但它是我们和复杂系统对抗时的盾牌。

这些模式我不是一口气学会的，而是在每次踩坑、重构、Review 中慢慢体会出来的。设计模式不是为了“用而用”，而是在需要它的时候，知道它能解决什么问题。

如果你也有类似的业务场景，欢迎留言交流！

👏 如果你觉得这篇内容有帮助，不妨点个赞，或者分享给你团队里的小伙伴！