设计模式 > 单一职责原则

SOLID原则并非单纯的1个原则，而是由5个设计原则组成的，它们分别是单一职责原则，开闭原则，里氏替换原则，接口隔离原则和依赖反转原则。

单一职责原则（SRP）

定义：一个类或者模块只负责完成一个职责（或者功能）。

从定义来看，一个类只负责完成一个职责或者功能。也就是说，不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它的职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。

单一职责被定义为“引起变化的原因”。如果我们有两个动机去改写一个方法，那么这个方法就具备两个职责。如果一个方法承担了太多职责，那么在需求变化过程中，需要改写的可能性就越大。

SRP 原则在很多设计模式中都有着广泛的运用，例如代理模式、迭代器模式、单例模式和装饰者模式。

举例：

在社交产品中，我们用UserInfo对象来记录用户的信息。UserInfo的设计是否满足单一职责原则。

UserInfo = {
  userId: stirng,
  username: string,
  email: string,
  telephone: string,
  createTime: string,
  avatar: string,
  provinceOfAddress: string, // 省  
  cityOfAddress: string, // 市
  regionOfAddress: string, // 区
  // ...... 其他属性和方法
}

1、UserInfo对象包含的都是跟用户相关的信息，所有属性都属于用户这样的一个模型，满足单一职责原则

2、地址信息在UserInfo对象中，可以继续拆分成独立的UserAddress，UserInfo只保留其他信息，拆分之后更加单一。

如果在这个产品中，用户信息和其他信息一样，只是单纯展示，那么UserInfo就是合理的，如果用户的地址信息还用在电商物流中，那么最好将地址信息拆分出来，独立成用户物流信息或者叫地址信息、收获信息。

评价一个类或者对象职责是否单一，并没有非常明确、可以量化的标准。在真正的开发中，没必要过于未雨绸缪，过度设计，为了设计而设计。

何时应该分离职责

1、在ajax请求的时候，创建xhr对象和发送xhr请求几乎总是在一起的，那么创建xhr和发送xhr的职责就没必要分开

2、职责的变化轴线仅当它们确定变化时才有意义，即使两个职责已经耦合在一起，但它们还没有改变的征兆，没必须主动分离，在重构的时候分离也不迟。

违反SRP原则

比如jQuery中attr方法，明显违反了SRP原则。jQuery的attr方法非常庞大，即负责取值，又负责赋值。但是对于用户来说，简化了用户的使用。

SRP优缺点

优点：降低了单个类或者对象的复杂度，按照职责把对象分解成更小的粒度，有助于代码的复用，也有利于进行单元测试。当一个职责需要变更的时候不会影响其他的职责。

缺点：增加代码的复杂度。当我们按照职责把对象分解成更小的粒度之后，实际上也增大了这些对象之间相互联系的难度。