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

最近看了同事的代码，感觉甚是优雅，再看看自己的，不禁自惭形秽，为了提高代码的可扩展性和可维护性等，是时候好好学习一下设计模式了。在学习设计模式之前，需要先看一下设计原则，因为设计原则是核心思想。就好比练剑，设计原则是心诀要领，设计模式是招式。

我们常说的SOLID原则，是包括单一职责原则、开闭原则、里式替换原则、接口隔离原则和依赖反转原则这五个，与五个英文字母一一对应。 今天，就先来看一下单一职责原则。

什么是单一职责原则呢？

英文：Single Responsibility Principle，缩写SRP。英文描述：A class or module should have a single reponsibility.(一个类或模块只负责完成一个功能)

这个定义很好理解，比如我们开发的时候要实现一个filter组件，不仅实现了搜索的功能，还把搜索之后的行为定义了出来，例如把搜索结果作为参数发送请求。搜索和发送请求是两个不同的功能，再说搜索之后不一定是发送请求，还可能是其他的行为，这就影响了组件的复用性，违反了单一职责原则。

所以对于类或模块或者函数等，不要设计的大而全，尽量粒度小、功能单一，只包含一个职责。如果包含多个职责，在需求变更的过程中，就有可能因为修改其中一个职责而引起其他职责出现bug。

如何看类或方法是否满足单一职责原则呢？

单一职责原则理解起来很简单，我们都知道啥意思，但在具体应用中还是有些难度的。不同的应用场景、需求阶段、业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。

下面通过一个例子让我们一起来学习一下。就拿疫情期间学生上网课来说吧，StudentInfo类大致会包含以下字段：

class StudentInfo {
  private name: string; // 姓名
  private age: number; // 年龄
  private class: string; // 班级
  private date: string; // 上课日期
  private onlineStartTime: string; // 网课开始时间
  private onlineEndTime: string; // 网课结束时间
  private province; // 省
  private city; // 市
  private region; // 地区
  private detailedAddress;  // 详细地址
}

上面的这些字段能否都归属于StudentInfo类呢？它符不符合单一职责原则呢？如果初始这个系统很简单，所有的信息都只是用来展示而已，那都放到一起也没有问题，因为它们也确实都是学生的信息。后来有了新的需求，老师想看一看各个班级学生的网课情况，由于要对网课相关的信息做更多的处理，就可以把date、onlineStartTime、onlineEndTime字段拆分出来，独立成一个类。经过对网课情况的分析，发现有些学生经常网课迟到，那是不是某些地区网络不好等情况影响的啊，这就需要地址信息做更多的分析操作，也就可以把地址信息单独拆分出来。

所以，在不同的需求阶段或不同的业务背景应用场景下，对一个类是否职责单一的判定也是不同的。我们可以根据对业务的理解程度，预测之后可能会有哪些功能，来设计职责单一的类或模块。但很多时候我们无法预测之后的需求走向，这时可以先写粗粒度的类，之后根据需求变更再不断重构，毕竟重构也是开发的一部分，可以让代码保持可读性、可维护性、可扩展性等。

现在我们知道判断类是否职责单一是一个很靠感觉的东西，不像算法题有固定的解法，这也是它在实施的过程中比较困难的地方。我在《设计模式之美》专栏中看到了王争老师给出的一些判断指标很具有指导意义，出现下面的情况就可能说明类的设计不满足单一职责原则：

• 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性
• 类依赖的其他类过多，或依赖类的其他类过多，不符合高内聚、低耦合的思想
• 私有方法过多，就要考虑能否将私有方法独立到新的类中，设置为public，供更多的类使用，提高代码复用性。
• 比较难给类起一个合适的名字，很难用一个业务名词概括，或只能用笼统的词语来命名，就说明类的职责可能不够清晰
• 类中大量的方法都是集中操作类的某几个属性，就可以考虑将这几个属性和对应的方法拆分出来。

为了满足单一职责原则，是不是要把方法或类设计的越单一越好呢？

大家都听说过“过犹不及”这个词，什么事都得有个度，如果为了追求单一职责原则而过度拆分，也会影响代码的可读性和可维护性。

不管使用什么设计原则和模式，提高代码的可读性、可维护性、可扩展性、复用性，使代码高内聚、低耦合才是目的。