SOLID原则在上个世纪80年代被发明出来。
源于Uncle Bob在设计USENET程序是对一些软件开发原则的争吵。
经过了一些修改，Uncle Bob在2000年早些时候进行了阐述。
直到2004年这些原则被整理成为SOLID原则，这是5个独立设计原则名字的首字母缩写。
- S represents the Single Responsibility principle（单一职责原则）
- O represents the Open Closed principle （开放封闭原则）
- L represents the Liskov Substitution principle （里氏替换原则）
- I represents the Interface Segregation principle （接口隔离原则）
- D represents the Dependency Inversion principle （依赖倒置原则）
当进行独立的模块开发或者大型架构设计时，SOLID原则非常实用。
单一职责（SRP）
单一职责试图提高一个类、模块、或者函数的凝聚力。凝聚力是对模块内部功能的之间的一个描述。
SRP可能是最容易让人误解的一个原则，单看名字很容易理解为一个模块只应该做一件事情，但是SOLID里的SRP却不是这个含义。
为了让大家理解这个原则背后正在的含义，有这样一句用于补充的描述：
一个软件模块有一个，且仅有一个让它改变的理由。
当这句话似乎并没有说明白这个理由到底是啥？
为了解决这个疑问，Uncle Bob在2014年写了一篇文章单独说明了这个理由到底是啥。
以人为本
我们开发一个应用，实际上是实现某些人的诉求，应用是否改变，本质上都来源于人的意志。
一个模块应该允许哪一些来指导变更，就变的很重要。
这个原则实际上是想表达，一个类，模块或者函数只应该允许一个人请求变更。
当得知这个原则的本质后，我回想起了很多线上事故，都能追述到不同的需求方在要求修改同一个页面的内容。
刚好这个页面并没有做好隔离，没有把每个需求方的代码隔离在不同的区域，导致这些变更非常容易出现错误，且变更起来异常困难。
可现实就是存在多个部门想在一个用户经常访问的页面添加功能。
产品想加一些数据展示模块。
增长想加引导分享弹窗。
运营想上一个活动广告位。
这些功能可能都会做成单独的组件，但是它们会同时由页面组件进行调度。
在每一次有人来为这个页面添加功能时，都不可避免要修改页面组件，这就导致了页面组件被更新的理由变得多样。
除非我们固定页面的调度机制，在添加或者修改页面功能时做到并不需要修改页面组件本身。
而且把每个部门对应修改的逻辑单独聚合起来，才能做到SRP原则里描述的那样。
确保每个类、模块、函数都只对一个特殊的需求方负责，是一个写好代码的重要原则。
也是最难的一个原则，因为这不是写代码的人能完全控制的，多方想改同一个逻辑的情况不是极少数，这就要求我们能对需求进行上游控制，至少确保某个逻辑的上游只有一个对接人。
参考文章：
Clean Coder Blog
https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html
https://hackernoon.com/understanding-solid-principles-in-javascript-w1cx3yrv