面向对象设计原则：为什么你的代码迟早会崩成"意大利面"

凌晨两点，你接到一个电话——线上支付系统故障，需要紧急修复。你打开代码库，找到那个 UserService 类，准备改一行逻辑。然后你发现：这个类里塞了用户验证、订单处理、邮件发送、日志记录、第三方支付对接……总代码量 3000 行，一个方法套一个方法，调用层级深达7层。

你改完支付逻辑，单元测试跑不过。你发现你的改动影响了另一个你完全不知道存在的功能。

这不是段子，这是真实发生的。Stripe 前工程负责人说过一句话："我们最昂贵的代码，都是那些没人敢动的代码。"

而 SOLID 原则，就是防止你的代码变成这种"恐怖片"的设计手册。

---

七条原则的本质：都是在解决"改一处，伤全身"

先说最重要的观察：SOLID 七条原则（SRP/OCP/LSP/DIP/ISP/CRP/LoD），听起来是七个独立概念，本质上都在回答同一个问题——当需求变化时，你的代码需要改多少？

一条原则如果被违背，症状很明显：改一个小需求，动辄需要理解整个系统。 这就是所谓的"大泥球"（Big Ball of Mud）架构。

1. 单一职责：一个类只做一件事，这句话骗了无数人

单一职责原则（SRP）听起来最简单，做起来最难。

什么叫"一件事"？用户类管用户信息算一件事，那验证用户算不算？存储用户算不算？发送欢迎邮件算不算？

真实项目中，最常见的违背方式是：把"变化原因"不同的逻辑塞进同一个类。

举个例子。你写了一个 Order 类：

class Order {
    double calculatePrice() { ... }      // 定价逻辑（业务规则）
    void saveToDatabase() { ... }       // 持久化（数据访问）
    void sendEmail() { ... }            
      { ... }         
}