定义：
不要存在多于一个导致类变更的原因。通俗地讲，一个类只做一件事情。
单一职责原则的好处：
1.类的复杂性降低，实现什么职责都有清晰明确的定义；
2.可读性提高，复杂性降低，那当然可读性提高了；
3.可维护性提高，可读性提高，那当然更容易维护了；
4.变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。
建议：
接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化
SRP好处:
组织代码、减少脆弱、更松耦合、代码改变、维护性、易于测试、易于调试
哪些地方需要单一职责？
方法、类、包、模块
如何识别SRP被破坏？
如何识别SRP被破坏？
1.类有太多依赖 构造器有太多参数，意味着测试有太多依赖，需要制造mock模拟太多测试输入参数，通常意味着已经破坏SRP了
2.方法有太多参数 类似类的构造器，方法参数意味着依赖
3.测试类变得复杂 如果测试类有太多变量，意味着这个类有太多职责
4.类或方法太长 如果方法太长，意味着内容太多，职责太多。一个类不超过200-250
5.描述性名称 如果你需要描述你的类，方法或包，比如使用“xxx和xxx”这种语句，意味着可能破坏了SRP
6.低聚合Cohesion类 低聚合特点：一个类有两个字段，其中一个字段被一些方法使用；另外一个字段被其他方法使用
7.在一个地方改动影响另外一个地方 如果在一个代码地方加入新功能或只是简单重构，却影响了其他不相关的地方，意味着这个地方代码可能破坏了SRP
8.猎枪效果Shotgun Effect 如果一个小的改变引起一发动全身，这意味SRP被破坏了
9.不能够封装模块