1.前言
单一职责原则,从字面上看,就是坚持一个对象一个职责。其实,如果一个程序员没有学过设计模式的六大原则,如果他会自己思考总结,写出来的代码基本上都是一个地方一个职责。因为当修改一个地方职责的时候,不会影响到另外一个职责,所以不用顾虑一处的修改,导致多处出现问题。
2.正文
2.1 单一职责原则定义
不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。
2.2 单一职责原则优点
- 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;
- 提高类的可读性,提高系统的可维护性;
- 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
2.3 职责扩散
编写软件坚持单一职责很容易做到,但是随着需求的扩张,一个类的职责可能由1个变细为两个,这个时候,这个类就不符合单一职责原则了,这就是职责扩散。所谓职责扩散,就是因为某种原因,职责P被分化为粒度更细的职责P1和P2。
2.4 职责扩散是否应该马上重构
因为某种原因,职责P被分化为粒度更细的职责P1和P2,那么是否应该把这个类重构成两个单独职责的类?不是的。在现实中,把一个类重构成两个类是比较麻烦的,所以一般是在原来类的基础上进行扩散。但是当扩散的职责已经快要超出我们的控制范围之前,就要马上进行重构。
2.5 职责扩散处理方法
随着需求的发展,容忍违背单一职责原则,必须坚持以下原则:
- 只有逻辑足够简单,才可以在代码级别上违反单一职责原则(不新建方法,不新建类,直接修改代码);
- 只有类中方法数量足够少,才可以在方法级别上违反单一职责原则(通过添加一个方法,对应新的职责,保证方法单一职责);
- 如果违背以1和2两点,则需要进行重构。
实际应用中的类都要复杂的多,一旦发生职责扩散而需要修改类时,除非这个类本身非常简单,否则还是遵循单一职责原则的好
3.参考资料
1.设计模式