设计模式三——单一职责原则



一、单一职责原则：就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责过多，就等于把这些职责都耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时， 设计会遭受意想不到的破坏。

二、描述：一般我们在进行代码设计的时候都会遵循单一职责原则，就是说将不同职责放在不同的类中。会破坏单一职责的情况主要是对原有的职责进行了扩展或者是细分。比如说，原来又指责A，后来对于职责A进行类细分，变成类A1和A2，或者说添加类新的职责B。这时候我们对于是否继续遵循就需要进行考量，即是对原始类进行修改还是说将原始类进行重写，进一步的细分。这边主要考虑的以下几个方面

1.当前修改的工作量

2.对已有职责的影响是否过大，会不会造成已有职责功能的变化

3.后期再次拓展的工作量

四、优缺点

优点：

1. 降低了类的复杂程度，一个类只负责一个职责比一个类负责多个职责简单的多

2. 提高了代码的可读性

3. 提高了代码的可维护性，修改一个类，不会对其他类有影响

4. 降低变更代码引起的风险

5. 提高了代码的可测试性

缺点：

单一职责会对类进行拆分，修改所引起的开销比较大

五、总结：在前期设计时，要遵循代码的单一职责原则，在后期修改时，针对修改引起的开销和后续的修改开销进行考虑是否继续遵循单一职责原则

引用：<<大话设计模式>> （程杰）

原文地址：https://www.jb51.cc/javaschema/284584.html