设计原则--单一职责原则

1、原则的定义

2、原则设计的初衷

3、能解决哪些问题

4、有哪些场景可以使用

 

单一职责原则，英文名Single Responsibility Principle,缩写为SRP。一个类或者模块只负责完成一个职责（或者功能）。也就是说，不要设计大而全的类，要设计粒度小，功能单一的类。换个角度来讲就是，一个类包含两个或者两个以上业务互不相干的功能，那我们就说它职责不够单一，应该将它差分为多个功能单一，粒度更细的类。

上面是从类的角度来描述单一职责原则，同样对于一个模块，一个函数亦是如此。

 

“高内聚，松耦合”是一个非常重要的设计思想，能够有效的提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。

高内聚，就是指功能相近的代码放到同一个类中，不相近的代码不要放到同一个类中，相近的共功能往往会被同时修改，放到同一个类中，修改会比较集中，修改的范围相对的也就会越小，代码容易维护。

松耦合，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类改动代码不会或者很少导致被依赖的类的代码的改动。

 

单一职责原则主要是为代码的编写提供指导意见，需要我们主观的去判断模块、类、方法是否满足单一职责原则，来实现代码的高内聚。提高代码的可读性和可维护性。

 

如何判定类的职责是否足够单一？

评判一个类的职责是否组个单一，并没有一个非常明确的，可以量化的标准。不同的场景，不同阶段的需求背景，不同的业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。实际上，在真正的软件开发过程中，为避免过度设计，我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以讲这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的重构。

比起需要主观的的去思考类是否职责单一，下面的几条判断标准可能更具有指导意义。

• 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性
• 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想
• 类中私有方法过多。
• 比较难给类起一个合适的名字，很难用一个名词来概括，说明这个类的职责不够单一
• 类中有大量的方法都是集中操作类中的某几个属性。

也就是说上面的几种情况可能不满足单一职责原则。需要对其进行拆分。

上面是从类的角度来判断职责是否单一，同样对于一个模块，一个函数也需要考虑其是否满足单一职责原则。

 

类的设计是否越单一越好呢？

我们通过单一职责原则避免设计大而全的类，避免将不相关的功能耦合在一起，来提高类的内聚性。但是如果拆分的过细，实际上会适得其反，反而降低代码的内聚性，也会影响代码的可维护性，这需要根据具体场景，具体分析，就同上面所述的一样，同一个类，在不同的场景，其单一职责原则的判定结果也会不一样。

 

参考：设计模式之美--王争