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

时间:2023-03-08 16:37:25
架构师之路——单一职责原则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.不能够封装模块