1.定义
任何一个类或者模块都应该只对某一个或一类行为者负责。
也就是说不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。
2.分析
为什么要遵循单一职责原则？
1）减少脆弱
当一个类有多个理由需要修改时，它变得脆弱，在一个地方的修改会导致其他地方不可预期的后果。
2）更松耦合
更多职责责任导致更高的耦合，高度耦合导致高度依赖，意味着难以维护。
3）代码改变
对于单一职责模块重构更容易。
4）维护性
维护一个单一职责的类比维护一个铁板一块的类更容易。
5）易于测试
测试单一目标的类只需要很少的测试类。
6）易于调试
在一个单一职责类找到问题是一件更容易的事情。
如何判断违反单一职责原则？
1）类有太多依赖
2）方法有太多参数
3）类或者方法太长
如果方法太长，意味着内容太多，职责过多。
4）名称不能用一个词来描述
如果你需要描述你的类 方法或包，比如使用"xxx和xxx"这种语句，意味着可能破坏了SRP。
3.案例
一个类的三个函数分别对应的是三类不同的行为者。使三类行为者的行为耦合在了一起，这可能会导致CFO团队的命令影响到COO团队所依赖的功能。
假设一种情况，calculatePay()方法和reportHours()方法使用相同的逻辑来计算正常工作时长，程序员为了避免重复编码，将该算法单独实现为一个名为regularHours的方法。当CFO团队修改了regularHours方法，但不知道reportHours方法也调用了regularHours方法，同时也影响了COO团队的功能。
改正的方法是，变成三个类，每个类只包含与之相关的函数代码，互相不可见，这样就不存在互相依赖的情况了。三个类共同使用一个不包括函数的、简单的数据类。
缺点是，使用者需要在程序里处理三个类。使用Facade设计模式来统一对外公布。
