《架构整洁之道》第 7 章 SRP：单一职责原则

均为原创，读架构整洁之道的笔记。

包含了部分自己的理解，包含了原书中至少 70% 的知识点。
完整笔记，各位老哥友链加起来吧。
我的博客地址：www.yuque.com/_huangkuan

单一职责原则（SRP：Single Responsibility Principle）。

这是SOLID五大设计原则中最容易被误解的一个。很多人认为这个原则只是：每个模块都应该只做一件事。这也确实是一个设计原则，但是容易使人认为只针对底层细节，即一个函数只做一个事，从而忽略了中层的设计。

任何一模块，都应当只对一个角色负责。接下来将用两个示例，解释这里的角色是什么意思。
示例 1 . 重复的假象
有一计算工资管理程序，Employee(员工)类。其中有三个方法，这些功能均是统计各部门的薪资计算办法，A方法导出财务需要的报表，B方法导出人事需要的报表，C方法导出IT需要的报表。其中A方法和B方法的薪资计算办法有部分计算功能共用，如共用了Z方法。
显然，这是有耦合的，接下来如果财务部门的统计办法有变动，刚好写A方法的和B方法的程序员不是同一个人，就有可能会去修改Z方法，从而导致B方法，即人事部门的薪资统计错误。
在此，我们可以将，财务，人事，IT ，理解为角色。即每个角色应当有自己的薪资计算模块，从而保证修改不会影响其他模块。
示例 2 . 代码合并
现在人事部门要求更改报表格式，IT部门要求增加字段，而刚好这两个需求分别是两个人在做，即他们都需要修改Employee类，这时他们的代码提交就很容易发生冲突。
避免这种问题产生的办法，依然是进行模块切分。
解决办法

将类拆分为3个，即按照角色写三个类，分别写自己的计算逻辑，再写一个雇员基础信息类，三个类共用一些基础数据。
如果使用第1种办法，在调用层就可能需要处理3个类。所以可以使用Facade模式，创建一个Facade，将三个类的调用和创建封装进一个类中。
还可以将雇员基础信息封装进Employee类中，将Employee中有独有的，仅一个部门使用的方法，转移到部门类，Employee中均为可公用的函数。
本章小结
单一职责，不仅是函数与类层面的事情。还应当是组件层面的。可以称为共同闭包原则。它用于奠定架构边界的变更核心。