单一职责原则(SRP)
就一个类而言，应该仅有一个引起它变化的原因。
单一职责原则的职责被定义为“引起变化的原因”。如果我们有两个动机去改写一个方法，那么这个方法就有了两个职责。每一个职责都是变化的一个轴线，如果一个方法承担了过多的职责，那么在需求的变迁过程中，需要改写这个方法的可能性就越大。特别是当两个职责耦合在一起的时候，一个职责发生变化可能会影响到其他职责的实现，造成意想不到的破坏。这种耦合性得到的是低内聚和脆弱的设计。
因此 SRP 原则体现为：一个对象（方法）只做一件事情。
设计模式中的 SRP 原则
SRP 原则在很多设计模式中都有着广泛的运用，例如代理模式、迭代器模式、单例模式和装饰者模式。
其中每个方法都应该只对应着一个职责。
何时应该分离职责
SRP 原则是所有原则中最简单也是最难正确运用的原则之一。
要明确的是，并不是所有的职责都应该一一分离。
一方面，如果随着需求的变化，有两个职责总是同时变化，那么就不必分离他们。比如在 ajax 请求的时候，创建 xhr 对象和发送 xhr 请求几乎总是在一起，那么创建 xhr 对象的职责和发送 xhr 请求的职责就没必要分开。
另一方面，职责的变化轴线仅当它们确定会发生变化时才有意义，即使两个职责已经被耦合在一起，但它们还没有发生改变的征兆，那么也许没有必要主动分离它们，在代码需要重构的时候再分离也不迟。
违反 SRP 原则
在人的常规思维中，总是习惯性地把一组相关的行为放到一起，如何正确地分离职责不是一件容易的事情。
一方面，我们受设计原则的指导，另一方面，我们未必要在任何时候都一成不变的遵守原则。在实际开发中，因为种种原因违反 SRP 的情况并不少见。比如 jQuery 的 attr 等方法，就是明显违反 SRP 原则的做法。jQuery 的 attr 是一个非常庞大的方法，既负责赋值，又负责取值，这对于 jQuery 的维护者来说，会带来一些困难，但对于 jQuery 的用户来说，却简化了用户的使用。
在方便性和稳定性之间要有一些取舍。具体是选择方便性还是稳定性，没有标准答案，而是要取决于具体的应用环境。
SRP 原则的优缺点
SRP 原则的优点是见底了单个类或者对象的复杂度，按照职责把对象分解成更小的粒度，这有助于代码的复用，也有利于进行单元测试。当一个职责需要变更的时候，不会影响到其他的职责。
但 SRP 原则也有一些缺点，最明显的是会增加编写代码的复杂度。当我们按照职责把对象分解成更小的粒度之后，实际上也增大了这些对象之间相互联系的难度。
