SOLID 设计原则：理解、适用场景与落地建议

为什么需要 SOLID

面向对象代码写多了之后，常见问题是：改一个功能牵动一堆模块、类越写越大、接口臃肿到没人敢动。SOLID 是五个针对这些问题的设计原则的缩写，它不是一套必须全部遵守的规范，而是一组诊断工具——当你觉得代码"不对劲"时，可以拿它们来定位问题出在哪一层。

适用场景：中大型 C++、Java、C# 等面向对象项目的日常设计与重构。对于脚本、一次性工具或纯函数式风格的项目，SOLID 的参考价值有限。

五个原则逐一说明

1. 单一职责原则（SRP - Single Responsibility Principle）

核心含义：一个类（或模块）应该只有一个引起它变化的原因。

生活类比：厨师专注做菜，服务员专注接待。如果让厨师同时负责收银，那么菜单调整和服务流程调整都会影响他，职责就混了。

代码层面：一个类只负责一件事。例如订单类只管理订单状态和明细，支付逻辑放到独立的支付服务中。判断标准不是"这个类有多少行代码"，而是"如果需求变了，这个类需要改吗？"如果多个不相关的需求都会触发修改，说明职责过多。

注意：SRP 的粒度取决于团队对"一件事"的共识。拆得太细会导致类爆炸，拆得太粗则回到大泥球。没有统一行数阈值，靠的是对变化轴的识别。

2. 开放封闭原则（OCP - Open/Closed Principle）

核心含义：对扩展开放，对修改关闭。新增功能时尽量不改动已有代码，而是通过扩展（新增类、注册策略等）来实现。

生活类比：插座标准固定（封闭修改），但可以插不同电器（开放扩展）。

代码层面：典型做法是定义抽象接口或基类，具体行为通过子类、策略对象或插件注册来扩展。例如日志输出格式变化时，新增一个 JsonFormatter 而不是去改已有的 TextFormatter。

注意：OCP 不是"永远不改旧代码"。如果每次扩展都要改基类签名，说明抽象设计有问题，此时修改是合理的。过度追求 OCP 会引入不必要的抽象层，增加理解成本。

3. 里氏替换原则（LSP - Liskov Substitution Principle）

核心含义：子类对象必须能替换父类对象，且程序行为不出现异常或语义错误。

生活类比：代驾服务，不管是谁来开车，都应该能安全到达目的地。如果某个"代驾"到了目的地把车锁了不让你走，那就违反了预期。

代码层面：子类不能强化前置条件（要求调用者做更多事），不能弱化后置条件（承诺更少的结果），不能改变不变量。一个常见反例：父类 Shape 有 getArea() 方法，子类 Line 继承后 getArea() 返回 0 或抛异常——调用方按父类语义使用就会出问题。

注意：LSP 违反往往比 SRP 违反更隐蔽，因为它不报编译错误，只在运行时或特定输入下暴露。写单元测试时，用父类引用调用子类方法，是验证 LSP 的实用手段。

4. 接口隔离原则（ISP - Interface Segregation Principle）

核心含义：客户端不应该被迫依赖它不使用的方法。接口要小而精准。

生活类比：银行服务窗口，存款窗口专门办存款，贷款窗口专门办贷款。你不会因为想存钱就被要求先填贷款申请表。

代码层面：如果一个接口里有 10 个方法，而某个实现类只需要其中 2 个，那它被迫实现了 8 个空方法或抛出未实现异常的方法。更好的做法是拆成 IDepositor、ILoanApplicant 等小接口。

注意：ISP 和 SRP 有重叠但关注点不同——SRP 关注类的职责，ISP 关注接口的粒度。在 C++ 中，由于没有强制接口概念，ISP 更多体现在头文件组织和虚函数表设计上。拆接口不是越多越好，两个方法如果总是一起被调用，合在一起反而更清晰。

5. 依赖倒置原则（DIP - Dependency Inversion Principle）

核心含义：高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

生活类比：组装电脑，不依赖具体的显卡型号，只依赖显卡接口标准（PCIe）。换显卡不用换主板。

代码层面：订单服务不直接 new 一个 MySQLOrderRepository，而是依赖 IOrderRepository 接口，具体实现在运行时注入。好处是：换数据库、写单元测试 mock、做集成测试时，不需要改订单服务的代码。

注意：DIP 在 C++ 中常通过抽象基类 + 工厂或依赖注入容器实现。但并非所有依赖都需要抽象——如果某个依赖确实只有一个实现且短期内不会变，直接依赖具体类更简单。DIP 的价值在"变化点"，不在"所有点"。

按项目规模取舍

SOLID 不是 checklist，不是每个项目都要五原则全上。实际工作中的常见分布：

• 小项目（几人、几周交付）：主要用 SRP 保持类不臃肿，适度用 OCP 为已知变化留扩展点。其余原则大概率用不上，强行套用反而增加理解成本。
• 中型项目（多人协作、持续迭代）：SRP + OCP 是基础。DIP 在模块间解耦时常用（比如业务层不直接依赖具体存储实现）。ISP 在对外接口设计时考虑，避免下游被迫实现无关方法。
• 大型项目（多团队、长生命周期）：五个原则都可能涉及，但仍然是按需使用。核心原则是：在变化频繁的地方投入设计精力，在稳定区域保持简单。

如何判断是否需要应用某个原则

遇到具体代码时，可以用以下问题做快速诊断：

这些判断没有标准答案，最终取决于团队对维护成本的评估。

风险与边界

• 过度设计：对一次性脚本或原型代码套用 SOLID，会引入大量抽象层，让代码更难读。原则是"先让代码能工作，出现问题时再重构"。
• 团队共识：如果团队对某个原则的理解不一致，强行推行只会产生混乱。先对齐"我们怎么理解 SRP"比"我们用了 SRP"更重要。
• 语言特性影响：SOLID 最初在 C++/Java 等强类型 OOP 语言的讨论中形成。在 C++ 中，模板、CRTP、组合优于继承等惯用法可能让某些原则的适用方式不同。在 Go、Rust 等语言中，接口和继承的机制不同，SOLID 的映射需要调整。
• 性能考量：抽象层（虚函数、接口注入）在 C++ 中可能带来间接调用开销。在热路径上，需要权衡设计清晰度和性能，不能盲目抽象。

开发建议

1. 先让代码能工作，出现问题时再重构。不要在设计阶段就试图满足所有原则。
2. 不要过度设计，团队理解和维护成本比理论上的"完美架构"更重要。
3. 重构时一次只解决一个问题。比如这次只拆 SRP，下次再考虑 DIP，避免大范围改动引入新 bug。
4. 用测试保护重构。在应用某个原则之前，确保现有行为有测试覆盖，改完跑一遍确认没破坏功能。

小结

SOLID 是一组诊断工具，不是必须全部执行的清单。它的价值在于帮你识别代码中的耦合、职责混乱和扩展困难，然后有针对性地改进。实际项目中，根据团队规模、迭代节奏和语言特性做取舍，比机械套用五原则更有效。

<!-- csdn-article-id: 144574781 -->

---

本文最初于 2024/12/19 发布在 CSDN。