背景介绍
这是我的《架构整洁之道》系列的第六篇，这一篇我们将一起学习 SRP 单一职责原则～
《架构整洁之道》系列：
SRP 单一职责原则
SRP 原则总是被误解，有很多程序员认为这个原则的内涵是：每个模块都应该只做一件事。
但是其实并不是这样的，与之混淆的设计原则为：一个函数只完成一个功能，我们在重构复杂函数的时候经常会使用这个原则，但这只是一个面向底层实现细节的设计原则，并非 SRP 原则的全部。
对 SRP 原则的描述应该为：任何一个软件模块都应该只对某一类行为者负责。
这里的行为者指的是：一个或多个有共同需求的人。
这里的软件模块指的是：一组紧密相关的函数和数据结构，“相关”这个词实际上就隐含了 SRP 这一原则。代码与数据就是靠着与某一类行为者的相关性被组合在一起的。
这里我举一个例子：
网络异常，图片无法展示
|
某个工资管理程序中的 Employee 类有三个函数: calculatePay()、reportHours() 和 save()。
- calculatePay() 函数是由财务部门制定的，他们负责向 CFO 汇报
- reportHours() 函数是由人力资源部门制定并使用的，他们负责向 coo 汇报
- save() 函数是由 DBA 制定的，他们负责向 CTO 汇报
程序员这样做实际上就等于使三类行为者的行为耦合在了一起了，违反了 SRP设计原则
针对上面这个问题，解决方案也很简单：
网络异常，图片无法展示
|
将相关的函数划分成不同的类。
网络异常，图片无法展示
|
或者如上图采用 facade 模式，EmployeeFacade 类仅需要包含初始化和调用三个具体实现类的函数。
结束语
网络异常，图片无法展示
|
单一职责原则主要讨论的是函数和类之间的关系一一但是它在两个讨论层面上会以不同的形式出现。在组件层面，我们可以将其称为共同闭包原则，在软件架构层面，它则是用于奠定架构边界的变更轴心。
最后
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
少年向来不识天高地厚
放眼处皆自负才高八斗
虽是自命风流
倒也坦诚无忧
我爱这样的少年
谦和而狂妄
骄傲又坦然☀️
✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨
