【Design】《The 6 Principles of Object-Oriented Design》

设计模式（23种设计模式）并不是凭空发明出来的，它们大多遵循 面向对象设计的 6 大原则（SOLID + 迪米特法则）。

可以理解为：

text 复制代码

设计原则  →  设计模式  →  具体代码

就像：

text 复制代码

交通法规  →  驾驶技巧  →  开车

先有原则，再有模式。

文章目录

[1. 单一职责原则（Single Responsibility Principle，SRP）](#1. 单一职责原则（Single Responsibility Principle，SRP）)
[2. 开闭原则（Open-Closed Principle，OCP）](#2. 开闭原则（Open-Closed Principle，OCP）)
[3. 里氏替换原则（Liskov Substitution Principle，LSP）](#3. 里氏替换原则（Liskov Substitution Principle，LSP）)
[4. 接口隔离原则（Interface Segregation Principle，ISP）](#4. 接口隔离原则（Interface Segregation Principle，ISP）)
[5. 依赖倒置原则（Dependency Inversion Principle，DIP）](#5. 依赖倒置原则（Dependency Inversion Principle，DIP）)
[6. 迪米特法则（Law of Demeter，LoD）](#6. 迪米特法则（Law of Demeter，LoD）)
[一张图记住 6 大原则](#一张图记住 6 大原则)
在实际开发中什么时候最有感？

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

核心思想

一个类只负责一件事。

错误示例

java 复制代码

class UserService {
    void login() {}
    void register() {}
    void sendEmail() {}
    void generateReport() {}
}

这个类既负责：

用户管理
邮件发送
报表生成

职责太多。

改进

java 复制代码

class UserService {}
class EmailService {}
class ReportService {}

每个类只负责自己的事情。

小学生版

学校里：

text 复制代码

班长
学习委员
体育委员

各管各的。

不要：

text 复制代码

一个同学
负责全班所有事情

否则累死。

实际工程

例如 YOLO 项目：

text 复制代码

Dataset
Model
Trainer
Validator

分别负责：

数据
模型
训练
验证

而不是全部塞进一个类。

2. 开闭原则（Open-Closed Principle，OCP）

核心思想

对扩展开放，对修改关闭。

新增功能：

text 复制代码

尽量新增代码
不要修改旧代码

例子

支付系统：

java 复制代码

interface Payment {
    void pay();
}

已有：

java 复制代码

class WeChatPay
class AlipayPay

新增：

java 复制代码

class ApplePay

直接扩展即可。

不用：

java 复制代码

if(type=="wechat")
if(type=="alipay")
if(type=="apple")

不断修改旧代码。

小学生版

插线板：

text 复制代码

增加新电器
直接插进去

而不是：

text 复制代码

每买一个电器
拆一次墙

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

核心思想

子类必须能够替换父类。

正确

java 复制代码

Animal
 ├─ Dog
 └─ Cat

哪里需要：

java 复制代码

Animal

都能传：

java 复制代码

Dog
Cat

错误经典案例

java 复制代码

Rectangle

继承：

java 复制代码

Square

因为：

text 复制代码

正方形 ≠ 长方形

行为不同。

违反里氏替换。

小学生版

如果老师说：

text 复制代码

带一只动物来

你带：

text 复制代码

小狗

没问题。

但如果带：

text 复制代码

机器人

就不行。

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

核心思想

不要让一个类依赖它不需要的方法。

错误

java 复制代码

interface Animal {
    fly();
    swim();
    run();
}

企鹅：

java 复制代码

class Penguin implements Animal

结果：

java 复制代码

fly()

根本不会飞。

很尴尬。

正确

拆分：

java 复制代码

interface Flyable {}
interface Swimmable {}
interface Runnable {}

需要什么实现什么。

小学生版

学校发了一张万能学生证：

学生证

text 复制代码

□ 游泳馆
□ 图书馆
□ 实验室
□ 停车场
□ 教师办公室

一年级小学生：

只需要：

text 复制代码

✓ 图书馆

结果：

必须携带全部权限

这就有问题。

更合理的是：

text 复制代码

图书馆证
游泳馆证
实验室证

按需发放。

这就对应：

java 复制代码

interface Readable {}
interface Swimable {}
interface Experimentable {}

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

核心思想

依赖抽象（标准），不依赖具体实现。

高层模块不应该依赖低层模块，两者都应该依赖抽象。

错误

java 复制代码

class Person {
    Car car = new BMW();
}

Person绑死BMW。

正确

java 复制代码

class Person {
    Car car;
}

其中：

java 复制代码

interface Car {}

具体实现：

java 复制代码

BMW
Tesla
BYD

随便换。

text 复制代码

人
 ↓
汽车接口(Car)
 ↓
宝马
特斯拉
比亚迪

小学生版

家里的手机、电视、风扇都使用统一标准的插头。

因此：

换一个品牌的插座，

这些电器仍然能用；

换一个品牌的电器，

插座也不用改。

大家依赖的是"标准"，

而不是彼此。

这就是依赖倒置原则。

6. 迪米特法则（Law of Demeter，LoD）

也叫：

最少知道原则（Least Knowledge Principle）

核心思想

只和直接朋友说话。

错误

java 复制代码

person.getCompany()
      .getDepartment()
      .getManager()
      .getPhone()

访问链太长。

正确

java 复制代码

person.getManagerPhone()

由内部处理。

小学生版

你想借一本书。

正常：

text 复制代码

你
 ↓
图书管理员
 ↓
找到书

你不需要知道：

text 复制代码

第几排
第几个书架
第几层
第几个格子

如果你必须知道：

text 复制代码

图书馆布局

那以后图书馆重装修：

text 复制代码

全乱套

这就是：

text 复制代码

少知道
少耦合

一张图记住 6 大原则

原则	关键词	一句话总结
SRP	单一职责	一个类只负责一种职责
OCP	开闭原则	扩展开放，修改关闭
LSP	里氏替换	子类替换父类后行为保持正确
ISP	接口隔离	别逼别人实现不用的方法
DIP	依赖倒置	依赖抽象，不依赖具体实现
LoD	迪米特法则	少了解别人的内部细节

在实际开发中什么时候最有感？

很多开发者刚学设计模式时会觉得：

"这些原则很抽象，平时写业务代码根本用不到。"

实际上，当项目从：

text 复制代码

1000 行代码

增长到：

text 复制代码

10万+
100万+

时，这些原则开始体现价值。

例如你做过 YOLO 改模型：

text 复制代码

新增 Backbone
新增 Neck
新增 Attention
新增 Loss

如果代码遵循：

开闭原则
依赖倒置

你只需要：

python 复制代码

model = build_model(cfg)

增加一个 YAML 配置即可。

如果没遵循这些原则，可能需要改十几个文件，甚至引入新的 Bug。

所以设计模式的本质不是"炫技"，而是：

降低修改成本，提高代码可维护性和可扩展性。

对于 AI 工程来说，最常见、最有价值的通常是：

单一职责原则（模块拆分）
开闭原则（方便扩展新模型）
依赖倒置原则（配置驱动、插件化）

这三条几乎贯穿了从 PyTorch 框架到大型训练平台的设计。