单一职责原则

​

什么是单一职责原则？

单一职责原则是一种设计规则，主张每个软件组件应该只有一个主要职责或目的。当一个类或模块承担多个职责时，对其中一个职责的修改可能会无意中影响其他职责，从而产生难以维护和测试的脆弱系统。

“一个类应该只有一个变更的理由。” — Robert C. Martin

该原则的名称源于”一次只做一件事”的理念。在实践中，这意味着将不同的关注点分离到不同的模块中。例如，处理用户认证的类不应该同时格式化数据显示——这是两个不同的职责：安全和展示。当显示格式发生变化时，你不应该需要修改认证逻辑，反之亦然。

​

单一职责原则的三层理解

• 入门：识别代码中不同的”变更理由”。如果需求变化会迫使你出于多个目的修改某个类，那么该类可能违反了SRP。
• 实践：在函数层面同样应用SRP。一个函数应该做一件事：把输入转换为输出。如果你在描述一个函数时发现自己要说”而且”，就应该考虑拆分它。
• 进阶：使用”变更轴线”测试。问自己：“如果X领域的需求发生变化，我需要修改这个类吗？“如果多个领域都回答”是”，那么这个类就承担了多个职责。

​

起源

单一职责原则由Robert C. Martin（人称”Uncle Bob”）在其2003年出版的《敏捷软件开发：原则、模式与实践》一书中推广开来。Martin将SRP作为后来被称为SOLID原则的一部分引入——这是一套面向对象编程的五大设计指南。 这一概念本身早于Martin的正式表述。开发者早就认识到，将不相关的功能组合在一起会造成维护上的噩梦。然而，Martin将这一原则提炼为一条可检验的规则：计算一个类可能需要变更的理由数量。如果超过一个，就违反了SRP。 该原则随着更广泛的敏捷运动而获得关注，敏捷运动强调迭代开发和适应变化需求的能力。在敏捷背景下，易于修改的代码是有价值的——SRP通过减少不相关关注点之间的耦合直接实现了这一点。

​

核心要点

​

应用场景

​

经典案例

2003年，一家金融服务公司对其交易平台进行了重大改造。原始代码库有一个名为”Trade”的类，处理验证、持久化、通知、报表和风险计算。由于紧耦合，任何一个方面的变更——比如添加新的通知渠道——都需要对整个系统进行测试。 团队使用SRP进行了重构，将Trade类拆分为五个专注的类：TradeValidator、TradeRepository、TradeNotifier、TradeReporter和RiskCalculator。每个类只有一个职责，可以独立修改。 结果非常显著。由于回归测试要求而产生的原本需要数天才能修复的缺陷，现在可以在几小时内解决。添加新的通知渠道只需要修改TradeNotifier类即可。在接下来的一年中，团队报告新功能的部署时间减少了40%。 这个案例说明了SRP的实践价值：虽然分离职责的前期成本需要思考，但长期在可维护性和开发速度方面获得的收益是 substantial 的。

​

边界与失效场景

SRP最常见的误用是过度拆分。创建”每个方法一个类”反而适得其反，因为会产生一个难以导航的系统。该原则的核心是关于内聚性——将相关事物分组——而不是任意最小化类的大小。 另一个失败模式是错误识别职责。“变更理由”有时是主观的。一个同时处理信用卡和银行转账的PaymentProcessor可能看起来像是两个职责，但如果两者的业务逻辑紧密交织，拆分它们可能会增加复杂性。 边界条件：当由于耦合导致的变更成本超过管理更多组件的成本时，才应用SRP。从内聚的设计开始，当注意到一个类因多个不相关的原因需要变更时，再向SRP方向重构。

​

常见误区

​

相关概念

单一职责原则是一个设计原则家族的成员，这些原则共同促进软件的可维护性：

​

一句话总结