单一职责原则
单一职责原则的定义
单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则，由罗伯特·C.马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中提出的。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
- 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
- 当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。
单一职责原则的优点
单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。
- 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
- 提高类的可读性。复杂性降低，自然其可读性会提高。
- 提高系统的可维护性。可读性提高，那自然更容易维护了。
- 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。
如何看类或方法是否满足单一职责原则呢？
单一职责原则理解起来很简单，我们都知道啥意思，但在具体应用中还是有些难度的。不同的应用场景、需求阶段、业务层面，对同一个类的职责是否单一，可能会有不同的判定结果。
下面通过一个例子让我们一起来学习一下。就拿疫情期间学生上网课来说吧，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，供更多的类使用，提高代码复用性。
- 比较难给类起一个合适的名字，很难用一个业务名词概括，或只能用笼统的词语来命名，就说明类的职责可能不够清晰
- 类中大量的方法都是集中操作类的某几个属性，就可以考虑将这几个属性和对应的方法拆分出来。
为了满足单一职责原则，是不是要把方法或类设计的越单一越好呢？
大家都听说过“过犹不及”这个词，什么事都得有个度，如果为了追求单一职责原则而过度拆分，也会影响代码的可读性和可维护性。
不管使用什么设计原则和模式，提高代码的可读性、可维护性、可扩展性、复用性，使代码高内聚、低耦合才是目的。