『面试的底气』—— 单一职责原则｜8月更文挑战

前言

在面试高级前端时，往往会遇到一些关于设计模式的问题，每次都回答不太理想。恰逢8月更文挑战的活动，准备用一个月时间好好理一下关于设计模式方面的知识点，给自己增加点面试的底气。

在学习设计模式之前，首先要认识到设计模式是个编程思想，对任何编程语言都适用。其次要从设计模式的原则开始学习，故本文将详细介绍设计模式的原则之一单一职责。

官方定义

单一职责原则，英文缩写SRP，全称Single Responsibility Principle。

原始定义：There should never be more than one reason for a class to change。

官方翻译：应该有且仅有一个原因引起类的变更。

我的理解

在理解单一职责原则之前，来回顾一下类的定义：具有相同的属性和功能的对象的抽像的集合。里面有两个关键词：对象和抽象。

对象是一个自包含的实体，可用一组可识别的特性和行为来标识，比如说“人”就是一个对象，其有眼睛、鼻子、嘴巴等可识别的特性，还有吃饭、睡觉、写代码等可识别的行为。

“人”与“人”之间有不同的属性比如男性和女性，有不同的功能比如前端开发者和后端开发者，有相同的属性比如有眼睛、有鼻子，有相同的功能比如会吃饭、会睡觉。抽象的作用就是把相同的属性和功能提取处理，最后组成一个集合，叫做“人类”，那么“人类”就是一个类。

然后用一个例子来理解单一职责原则，比如你是房东，出租一套房子。租客可以当作一个个对象，房子可以看作一个类。租客（对象）会影响房子（类）给房东带来的房租。

单一职责原则就是要求房子只租给一个租客，只有一个租客会影响房子给房东带来的房租（一个原因引起类的变更）。如是出租给几个互相不认识的人，则会有好几个人会影响你的房租收入（好几个原因引起类的变更）。

用代码来表示：

class House {
    constructor(param) {
        this.data = param;
        this.name = param.name;
        //...
    }
    countMoney(data){
        //...
    }
    payMoney(){
        let data;
        //...
        const money = this.countMoney(this.data)
    }
}

以上代码的类House代表房子，里面集合了租客，countMoney方法用于计算房租，payMoney用于支房租。当new House(param)时就创建一套房子，通过param传递租客信息进去。

此时设想一下，起先租客只有一个人。计算租金很好算，countMoney方法中的逻辑很好写。后来又加了一些租客，countMoney方法得重写，出错还影响其他租客支付房租，甚至有些租客由于房租计算的规则不满意，不租了，这就影响到房东的房租收入。所以房子只出租给一个人，房租最好算，不会影响到房东的房租收入。

当然实际生活说，房子不可能只出租给一个人，也可以出租给一家子或者二房东，房东只跟一个租客结算房租，这样countMoney方法不至于频繁修改，只有向房东支付房租的租客变更后，才会去修改countMoney方法。

以上说到了租客不可能是一个人，那么职责中不可能只有单独一个方法，甚至职责还会包含其他子职责。那么如何把众多功能分别归属到对应的职责中，还有如何划分职责，就是架构设计时要考虑的事情了。

单一职责原则不单单只应用在类中，也可以应用在普通函数中，即一个函数只处理一件事件。

作用及优点

单一职责原则的作用是控制类的粒度大小、将对象解耦、提高其内聚性。其有以下优点：

• 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。

• 提高类的可读性。复杂性降低，自然其可读性会提高。

• 提高代码的可维护性。可读性提高，那自然更容易维护了。

• 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

难点

遵循单一职责原则的过程中，最大的难点就是职责如何划分，划分过细，会导致类过多，也会导致维护困难，划分过粗，可能会违背单一职责原则。