单一职责原则：提升代码质量的关键

海上孤帆

一、单一职责原则的定义与内涵
单一职责原则（SRP：Single responsibility principle）又称单一功能原则，是面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。该原则由罗伯特・C・马丁于《敏捷软件开发：原则、模式和实践》一书中给出，是基于汤姆・狄马克和 Meilir Page-Jones 的著作中的内聚性原则发展而来。
所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。
一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。
例如，要实现逻辑和界面的分离。如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。


二、单一职责原则的好处
（一）降低类的复杂度
当一个类只负责一项职责时，其内部的逻辑会更加清晰和简单。以交通工具为例，假如不遵循单一职责原则，将汽车、飞机、轮船等不同类型的交通工具的行驶功能都放在一个类中，那么这个类的代码会非常复杂。因为不同的交通工具行驶方式差异很大，比如汽车在公路上行驶，飞机在天空中飞行，轮船在水中航行。如果把这些功能都放在一个类中，就需要很多的判断逻辑来区分不同的行驶方式，代码会变得冗长且难以理解。而如果遵循单一职责原则，将不同类型的交通工具的行驶功能分别放在不同的类中，每个类只负责一种交通工具的行驶，那么每个类的代码就会非常简单，只需要实现特定交通工具的行驶逻辑即可。例如，汽车类只负责汽车在公路上的行驶逻辑，飞机类只负责飞机在天空中的飞行逻辑，轮船类只负责轮船在水中的航行逻辑。这样，每个类的复杂度就大大降低了。
（二）提高可读性和可维护性
职责明确的代码更容易被理解和修改，从而提高了可读性与可维护性。当一个类只负责一项职责时，其功能和目的非常明确，开发者可以很容易地理解这个类的作用。比如，一个负责用户登录的类，只包含用户登录的相关逻辑，如验证用户名和密码、处理登录异常等。开发者在阅读这个类的代码时，可以快速了解其功能，不需要花费大量时间去梳理复杂的逻辑关系。而且，当需要修改用户登录功能时，也可以很容易地找到对应的类进行修改，不会影响到其他不相关的功能。另外，如果代码的可读性高，那么在团队协作开发中，其他开发者也可以更容易地理解和维护代码，提高开发效率。
（三）降低变更风险
当一个功能变化时，遵循单一职责原则可以降低对其他功能的影响，从而降低变更带来的风险。例如，在一个电商系统中，如果将商品管理、订单管理和用户管理等功能都放在一个类中，当商品管理的功能需要修改时，很可能会影响到订单管理和用户管理的功能。因为这些功能耦合在一起，一个功能的变化可能会导致其他功能出现问题。而如果遵循单一职责原则，将商品管理、订单管理和用户管理分别放在不同的类中，当商品管理的功能需要修改时，只会影响到商品管理类，不会对订单管理和用户管理类产生影响。这样就大大降低了变更带来的风险。根据一些研究数据显示，遵循单一职责原则的项目在进行功能变更时，出现问题的概率比不遵循该原则的项目低 30% 左右。这充分说明了单一职责原则在降低变更风险方面的重要性。


三、对代码可维护性的提升
（一）清晰的职责边界
单一职责原则要求每个类只负责一项功能，这使得职责边界变得非常清晰。例如，在一个在线教育系统中，我们可以将课程管理、学生管理、教师管理等功能分别放在不同的类中。课程管理类只负责课程的创建、更新、删除等操作；学生管理类只负责学生的注册、登录、成绩查询等操作；教师管理类只负责教师的信息录入、课程安排、教学评价等操作。这样，每个类的职责都非常明确，不会出现职责混乱的情况。当需要对某个功能进行维护时，我们可以快速定位到相应的类，进行修改和完善。而且，由于职责边界清晰，不同类之间的耦合度也会降低，这使得代码的维护更加容易。
（二）方便定位问题
当代码出现问题时，单一职责原则可以帮助我们快速确定相关类，方便定位问题进行修复。如果一个系统中的类职责不明确，当出现问题时，我们可能需要花费大量的时间去排查各个类，才能找到问题所在。而如果遵循单一职责原则，每个类只负责一项功能，那么当出现问题时，我们可以根据问题的表现快速确定可能出现问题的类。例如，如果学生在登录系统时出现问题，我们可以直接定位到学生管理类，检查登录逻辑是否存在问题。这样可以大大提高问题定位的效率，减少修复问题的时间。
（三）促进代码重用
单一职责的类更容易被提取和在其他项目中使用，促进代码重用。因为每个类只负责一项功能，所以它的功能相对独立，通用性更强。例如，在一个电商系统中，我们开发了一个订单管理类，只负责订单的创建、查询、修改、删除等操作。如果我们在另一个项目中也需要订单管理功能，那么我们可以直接将这个订单管理类提取出来，稍加修改就可以在新的项目中使用。根据一些实际项目的数据统计，遵循单一职责原则的代码重用率可以提高 40% 左右。这不仅可以提高开发效率，还可以减少代码的重复开发，降低开发成本。


四、对可测试性的作用
（一）职责明确便于测试
单一职责原则使得每个类的职责明确，这为编写单元测试带来了极大的便利。当一个类只负责一项特定的功能时，我们可以更加清晰地确定测试的目标和范围。例如，在一个银行系统中，如果有一个专门负责账户管理的类，它的职责可能包括开户、销户、查询余额等操作。由于这个类的职责非常明确，我们可以针对每个操作编写独立的单元测试。比如，对于开户操作，我们可以编写测试用例来验证输入的客户信息是否正确被处理，账户是否成功创建等。同样，对于销户和查询余额等操作，也可以分别编写相应的测试用例。这样，每个测试用例都只关注一个特定的功能，使得测试更加简单、直接，也更容易发现问题。根据一些实际项目的统计数据，遵循单一职责原则的代码，其单元测试的编写时间可以减少 30% 左右，并且测试的覆盖率和准确性也更高。
（二）减少测试复杂性
在不遵循单一职责原则的情况下，一个类可能承担多个职责，这会导致复杂的测试场景，增加测试的难度和复杂性。例如，一个既负责数据处理又负责用户界面显示的类，在测试时需要同时考虑数据处理的正确性和用户界面的显示效果，这就需要设置复杂的测试环境和模拟多种不同的情况。而如果遵循单一职责原则，将数据处理和用户界面显示分别放在不同的类中，那么测试就会变得更加简单。对于数据处理类，我们只需要关注数据的输入、处理和输出是否正确；对于用户界面显示类，我们只需要关注界面的布局、颜色、交互等方面是否符合要求。这样，每个类的测试都更加独立和简单，避免了多个职责导致的复杂测试场景。研究表明，遵循单一职责原则可以降低测试复杂性约 40%，提高测试效率和质量。