架构师之路——单一职责原则SRP (我单纯，我快乐)

定义：

　　不要存在多于一个导致类变更的原因。通俗地讲，一个类只做一件事情。

 

单一职责原则的好处：

　　1.类的复杂性降低，实现什么职责都有清晰明确的定义；

　　2.可读性提高，复杂性降低，那当然可读性提高了；

　　3.可维护性提高，可读性提高，那当然更容易维护了；

　　4.变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

 

建议：

　　接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化

SRP好处:

　　组织代码、减少脆弱、更松耦合、代码改变、维护性、易于测试、易于调试

哪些地方需要单一职责？

　　方法、类、包、模块  
如何识别SRP被破坏？

　　1.类有太多依赖 构造器有太多参数，意味着测试有太多依赖，需要制造mock模拟太多测试输入参数，通常意味着已经破坏SRP了

　　2.方法有太多参数 类似类的构造器，方法参数意味着依赖

　　3.测试类变得复杂 如果测试类有太多变量，意味着这个类有太多职责

　　4.类或方法太长 如果方法太长，意味着内容太多，职责太多。一个类不超过200-250

　　5.描述性名称 如果你需要描述你的类，方法或包，比如使用“xxx和xxx”这种语句，意味着可能破坏了SRP

　　6.低聚合Cohesion类 低聚合特点：一个类有两个字段，其中一个字段被一些方法使用；另外一个字段被其他方法使用

　　7.在一个地方改动影响另外一个地方 如果在一个代码地方加入新功能或只是简单重构，却影响了其他不相关的地方，意味着这个地方代码可能破坏了SRP

　　8.猎枪效果Shotgun Effect 如果一个小的改变引起一发动全身，这意味SRP被破坏了

　　9.不能够封装模块