软件开发七大原则

1. 单一职责原则 SRP

一个类 / 模块，只应该有一个引起它变化的原因。
一句话：只干一件事。

反例：

• 一个类既处理用户登录，又写日志，又发邮件，又算报表。
• 改报表逻辑 → 可能把登录搞崩。

正例：

• Logon 只负责用户登录
• Logger 只负责日志
• Mail 只负责发邮件

好处： 改一处不影响别处，易测试、易维护。

2. 开闭原则 OCP

对扩展开放，对修改关闭。
不要去改已经稳定、上线的老代码。
新功能用继承、接口、组合扩展，而不是直接改原类。

反例：

• 每次加新支付方式（微信 / 支付宝 / 银联），都去改同一个 Payment 类。

正例：

• 定义 Payment 接口，每种支付写一个实现类，新增只加类，不改旧代码。

**核心：**代码越改越乱，越扩越稳。

3. 里氏替换原则 LSP

子类必须能完全替换父类，且不破坏原有逻辑。
子类不能破坏父类的 “约定”。
不能为了方便，随便重写父类方法导致行为异常。

经典反例：

• 父类：鸟 → 能飞
• 子类：鸵鸟 extends 鸟 → 重写飞 () 抛出异常
• 这就违反 LSP，因为鸵鸟不能替换 “鸟”。

正确做法：

• 把 “会飞” 抽成 Flyable 接口，不是所有鸟都实现。

核心： 继承不能乱来，子类要守父类的规矩。

4. 接口隔离原则 ISP

客户端不应该依赖它不需要的接口。
接口要小而专，不要搞 “万能大接口”。

反例：

• 一个 Animal 接口有 eat ()、sleep ()、fly ()、swim ()
• 鸡实现它，也要被迫写空的 fly ()、swim()，非常臃肿。

正例：

• 拆成：Eatable、Sleepable、Flyable、Swimable需要什么实现什么。

核心： 接口别贪大，按需拆分。

5. 依赖倒置原则 DIP

高层不依赖低层，都依赖抽象；
抽象不依赖细节，细节依赖抽象。
简单说：面向接口 / 抽象编程，不要面向具体实现。

反例：

• 业务类直接 new MySQLDao () → 换数据库必须改业务代码。

正例：

• 业务类依赖 IDao 接口，MySQLDao、OracleDao 都实现它。业务类只跟接口打交道，换数据库不碰业务。

核心： 依赖抽象，代码才灵活可替换。

6. 迪米特法则 LoD（最少知道原则）

一个对象对其他对象知道得越少越好。只跟直接朋友通信，不跟陌生人说话。
直接朋友包括：

• 当前对象自己
• 方法入参
• 成员变量
• 方法内创建的对象

反例：

• A 调用 B，B 调用 C，A 直接去调用 C 的内部方法 → 高度耦合。

正例：

• A 只调用 B，B 封装好逻辑再调用 C，A 不认识 C。

核心： 减少类之间纠缠，降低耦合。

7. 合成 / 聚合复用原则 CRP

优先使用组合 / 聚合，少用继承实现复用。
继承是强耦合：父类一改，所有子类遭殃。
组合是弱耦合：把其他对象当作成员变量使用。

反例：

• 为了复用数据库操作，让所有 Service 都继承 DBUtil。

正例：

• Service 里持有 DBUtil 对象，调用它的方法。

核心： 多用组合，少用继承。

总结

七大原则到底有什么用？

它们共同解决软件开发里最痛的 4 个问题：

1. 代码难维护 → 变得清晰、简单
2. 一改就崩 → 变得稳定、安全
3. 扩展困难 → 变得灵活、可插拔
4. 接手痛苦 → 变得规范、易读懂

最终效果：项目越大越不乱，需求越改越轻松，bug 越来越少，加班越来越短。
具体应用：C++23种设计模式