Single responsibility principle - 单一职责原则

单一职责原则 —— SRP

一个类应该只有一个发生变化的原因

Robert C. Martin敏捷软件开发：原则、模式和实践

  所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。(看看就行)

  如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

  内聚标志一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部化概念的自然扩展。内聚是从功能角度来度量模块内的联系，一个好的内聚模块应当恰好做一件事。它描述的是模块内的功能联系。耦合是软件结构中各模块之间相互连接的一种度量，耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。（T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。）

  程序讲究的是低耦合，高内聚。就是同一个模块内的各个元素之间要高度紧密，但是各个模块之间的相互依存度却要不那么紧密。内聚和耦合是密切相关的，同其他模块存在高耦合的模块意味着低内聚，而高内聚的模块意味着该模块同其他模块之间是低耦合。在进行软件设计时，应力争做到高内聚，低耦合。

实现单一职责原则的好处

1. 降低类的复杂度；
2. 提高类的可读性，提高系统的可维护性；
3. 降低变更引起的风险（降低对其他功能的影响）;

实现单一职责原则的注意点

1. 单一职责原则最难划分的是职责。
2. 单一职责原则提出标准：用职责和变化原因来

错误Demo

  假设机器有四个步骤分别为：通电，启动，停止，断电；我们正确的方式应该是每个步骤写一个方法，最后写一个方法的集合，内容：什么时候调用通电 什么时候启动，什么时候停止，什么时候断电，而不是直接将四个步骤集合在一起，如果四个方法集合在一起的话，首先的问题是职责太多，不用解释，其次如果有一天我们只需要启动这个机器 不需要别的步骤 还需要再次寻找方法集合中的启动有哪些 复制出来之后冗余太多，最后的问题是我们自己都看不懂自己当初怎么写的了 内容太多，逻辑加控制，假设现在新增加一个需求，机器在通电之后3分钟之内没有启动的话自动执行断电，到这个时候我们就会很麻烦 首先步骤需要重新调试，其次控制也需要增加逻辑等等一系列问题…..