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