单一职责原则¶
约 651 个字 11 行代码 1 张图片 预计阅读时间 3 分钟
场景：功能堆砌的手机¶
小菜用新手机拍摄 UFO，却因摄像效果太差无法作为证据。大鸟点破：职责过多的产品，往往在关键时刻“萎掉”。大多数时候，一件产品职责单一一些，或许是更好的选择——这与 单一职责原则 一致。
原则定义¶
单一职责原则（Single Responsibility Principle，SRP）：就一个类而言，应该仅有一个引起它变化的原因。
[Robert C. Martin, Agile Software Development]
换句话说：一个类只负责一块相对内聚的职责；当这块职责变化时，才需要修改这个类。
为什么要拆分职责¶
- 降低耦合：报表、权限、持久化混在一处，任何修改都可能波及其他逻辑。
- 提高可读性与可维护性：类名、方法名能直接对应业务概念。
- 复用更自然：只负责「用户校验」的组件可在多个用例中复用。
常见误区¶
- 不是「每个类只能有一个 public 方法」——职责按 变化原因 划分，不是按方法个数机械切分。
- 不是过度碎片化——拆得过细会产生大量薄包装类，增加导航成本。
案例：俄罗斯方块¶
若把所有代码写在 Form1.cs 里（绘制、键盘、碰撞、消层、计时器……），则：
- 换界面（如 Pocket PC）时 游戏逻辑无法复用；
- 界面变化与游戏规则变化 耦合在一起。
合理划分：
| 类 | 职责 |
|---|---|
| 游戏逻辑类 | 二维数组表示方块、下落、旋转、碰撞、消层 |
| 窗体/界面类 | 根据数组绘出/擦除、响应键盘 |
判断标准：若能想到 多于一个动机 去改变一个类，这个类就具有多于一个职责，应考虑分离。
简单对比¶
Java
// 职责混杂
class User {
String name;
void saveToDb() { /* JDBC ... */ }
}
// 更符合 SRP
class User { String name; }
class UserRepository {
void save(User u) { /* JDBC ... */ }
}
与其他原则的关系¶
SRP 是 SOLID 中的 S，也是后续 开放-封闭、依赖倒转 等原则的基础：职责不清的「上帝类」往往同时难以扩展、难以测试。
小结¶
软件设计的重要工作之一，是 发现职责并把职责相互分离。单一职责让代码更易维护、扩展、复用——正如大鸟所说，在类的职责分离上多思考，代码才会真正灵活。