设计原则 — S 单一职责原则

含义

对此原则具体描述下就是：一个类或者模块只完成一个职责。

更具体来说是要求不要设计大而全的类，要设计粒度小、功能单一的类。

优点

那这条原则具备什么优点呢？

我认为对应好代码的标准，体现在两方面的增强：可读性和可维护性。

1. 增强可读性要从人的思维方式讲起。

人善于用先整体后局部的思维方式来认识事物。也就是先对事物分类，再分别对每一类事物细化认识。所以若类或模块内的东西属于一个范畴，我们就可以采用这种先整体后局部的思维方式来处理，看到类或模块就知道会提供哪方面的功能。

现在假设你要找某个功能的实现，就可以先在类或模块上筛选，找到所属范畴后，再深入相应范畴的类或模块内做筛选；而不是深入到每一个类或模块的内部去筛选。

那若类或模块内的东西乱七八糟，就无范畴可言，也就无法应用先整体后局部的方式来做筛选。

讲到这里，联想到第一个人将 Java 中的 class 翻译成分类中的“类”，个人认为也并不是一个巧合，猜测面向对象中的“类”就是带有分类的意思。而单一职责其实就是回归分类这一本质。

所以显然单一职责原则可以增强代码的可读性。

1. 增强可维护性可以看当作出变更时是否具备便利。

同一范畴的东西内聚到同一个地方，假设这块范畴的东西要改，我不用漫无目的的四处寻找哪里需要改，可以快速定位到原来改的地方在这。

不说别的，找就具备了便利，所以显然也可以增强代码的可维护性。

如何做

这条原则的重点是单一职责，那如何做的重点其实就是如何判定职责是否单一。

我认为可按照我们平常的思维去确定，根据判定的难易程度来分为两类：

1. 直接一眼看出职责是否不一样

这个就不做过多说明了，就拿订单和客户举例，两个风马牛不相及的物体很容易就知道要拆开。

1. 需要深入分析职责是否不一样

需要在不同的应用场景、不同阶段的需求背景下对拆分粒度有所抉择。

因为不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能会不一样。

举例来说：客户信息里包含地址信息，当地址信息只是做一个普通收集时，地址信息包含在客户信息里没有问题；但当地址信息有其他作用时，比如邮寄，那地址信息单独拆走会比较合适。

对于这类拆分，只能针对具体场景具体分析，不要拆得过粗，也不要过细，无法给出一个标准答案。

这听上去就像一句废话🤣但事实如此，依赖于你的经验...

作者给出了一些可以具体量化的评判可做参考，但也仅做参考，具体有：

1. 类中的代码行数、属性过多

2. 类依赖的其他类过多

3. 私有方法过多

4. 较难为类概括一个合适的业务名字

5. 类中大量的方法集中操作某几个属性，可以考虑将这几个属性拆走

我认为 4、5 是比较准确的，1、2、3 还需多考虑考虑，但要问我为什么，我暂时说不出来，只是凭感觉。