单一职责原则

类的职责要单一,不要将太多的职责放在同一个类中。否则将会导致的后果是一个功能点的变更会导致其他正常功能点的破坏。 其实也就是我们经常强调的(高内聚、低耦合)

原则分析:

  1. 一个类(或者大到模块,小到方法)承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作。
  2. 类的职责主要包括两个方面:数据职责和行为职责,数据职责通过其属性来体现,而行为职责通过其方法来体现。
  3. 单一职责原则是实现高内聚、低耦合的指导方针,在很多代码重构手法中都能找到它的存在,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

好处

  1. 降低类的复杂性,类的职责清晰明确。比如数据职责和行为职责清晰明确。
  2. 提高类的可读性和维护性,
  3. 变更引起的风险减低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的类有影响,对其他接口无影响,这对系统的扩展性、维护性都有非常大的帮助。

注意:

单一职责原则提出了一个编写程序的标准,用"职责"或"变化原因"来衡量接口或类设计得是否合理,但是"职责"和"变化原因"都是没有具体标准的,一个类到底要负责那些职责?这些职责怎么细化?细化后是否都要有一个接口或类?这些都需从实际的情况考虑。因项目而异,因环境而异。

示例: