一些编程思想
这页汇总常见的代码设计原则，用于在重构、架构评审和实现取舍时快速校准：先保持职责清晰，再减少重复、控制复杂度，最后避免提前实现并不存在的需求。
快速索引
1. SOLID 原则
SOLID 是五个面向对象设计原则的首字母缩写，目的是让代码更健壮、可维护、易扩展。
| 缩写 | 原则名 | 含义 |
|---|---|---|
| S | 单一职责原则（Single Responsibility Principle, SRP） | 一个类只负责一项职责。不要让类“太多功能”，否则它变化的原因就太多。 |
| O | 开闭原则（Open/Closed Principle） | 软件实体应对扩展开放，对修改关闭。即通过继承或组合来扩展功能，而不是直接修改原代码。 |
| L | 里氏替换原则（Liskov Substitution Principle） | 子类必须能够替换父类出现的地方，行为保持一致。例如，不要破坏继承带来的多态性。 |
| I | 接口隔离原则（Interface Segregation Principle） | 不要强迫用户依赖他们不需要的接口，多个小接口好过一个大接口。 |
| D | 依赖反转原则（Dependency Inversion Principle） | 高层模块不应该依赖低层模块，二者都应依赖抽象。通过依赖接口而不是具体实现来解耦。 |
🔧 示例：依赖注入就是 D（依赖反转原则） 的一种实现方式。
✅ 2. DRY 原则
Don’t Repeat Yourself（不要重复自己）
核心思想：
避免复制粘贴相同的逻辑，多次出现的代码、规则、配置都应该提取到一个统一的地方。
举例：
-
有两段几乎一样的业务逻辑处理，应该提取成函数。
-
不同模块使用相同的常量，应提取到共享配置头文件。
-
数据模型校验规则重复，应统一封装。
🚫 错误示例：
if (user.age > 18 && user.verified) { /* A */ }
...
if (user.age > 18 && user.verified) { /* B */ } // 重复判断应该提取：
bool isValidUser(const User& user) {
return user.age > 18 && user.verified;
}✅ 3. KISS 原则
Keep It Simple, Stupid（保持简单，笨蛋）
核心思想：
代码应该尽量简单、直观、易理解。不要做过度设计或引入不必要的复杂性。
推荐实践：
-
用最简单的方式解决问题，不做“聪明”的 hack。
-
小函数，小类，命名清晰。
-
如果一段代码你都要解释才能看懂，可能就不够“KISS”。
🚫 错误示例：
为了“优雅”，搞一堆模板元编程、宏魔法，让维护者摸不着头脑。
✅ 正确示例：
用简单的 if/else/循环能写清楚的逻辑，不要硬上策略模式、反射框架。
✅ 4. YAGNI 原则
You Aren’t Gonna Need It（你不会需要它）
核心思想：
不要提前实现你现在用不到的功能。只实现当前明确需要的功能，不做过度设计。
说明：
-
写代码时经常想：“以后也许会需要这个功能”。但这个“也许”常常不会发生。
-
提前设计复杂扩展点、预留接口、引入插件系统，结果没人用，浪费开发时间和复杂度成本。
🚫 错误示例：
// 为一个只有一个产品类型的电商系统，预留多语言、多币种、多仓库✅ 正确做法：
根据实际业务推动演进，有需求再重构（配合良好架构和测试支撑）。