单一职责原则 （Single Responsibility Principle, SRP）
单一职责原则在设计模式中常被定义为“一个类应该只有一个发生变化的原因”，若我们有两个动机去改写一个方法，那这个方法就有两个职责。实际开发过程，修改代码本身就存在风险，特别是两个职责耦合在一起有依赖关系的时候，一个职责的变化可能对整个逻辑造成意想不到的破坏，这种耦合性得到的是低内聚和脆弱的设计。
SRP原则体现为：一个对象（方法）只做一件事
何时应该分离职责
SRP 原则是所有原则中最简单也是最难正确运用的原则之一。 要明确的是，并不是所有的职责都应该一一分离。
一方面，如果随着需求的变化，有两个职责总是同时变化，那就不必分离他们。比如在 ajax 请求的时候，创建 xhr 对象和发送 xhr 请求几乎总是在一起的，那么创建 xhr 对象的职责和发送 xhr 请求的职责就没有必要分开。
另一方面，职责的变化轴线仅当它们确定会发生变化时才具有意义，即使两个职责已经被耦 合在一起，但它们还没有发生改变的征兆，那么也许没有必要主动分离它们，在代码需要重构的 时候再进行分离也不迟。
通常我们习惯把相关的行为放在一起，所以实际开发过程中，看似简单的按职责分离其实也没那么容易，这时我们就需要在方便性和稳定性中做好取舍，比如jquery的attr方法，既可以用来赋值，又可以用来取值，从开发维护的角度来讲，这里违反SRP原则存在一定的维护成本，但却简化了用户的使用。在业务上下文强耦合的情况下，分离可能并不是更好的选择，这个时候就该考虑分离的必要性。职责分离并没有一定的标准，无需纠结，具体看开发时的业务场景进行合理选择就好。
优点
降低单个类或对象的复杂度，更细粒度地去管理对象，有助于代码的复用。
缺点
增加编写代码的复杂度，当我们按照职责来分解对象之后，实际上也增大了对象之间相互联系的难度。