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

“这是我参与8月更文挑战的第1天，活动详情查看：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方法。

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

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

做用及优势

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

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

• 提升类的可读性。复杂性下降，天然其可读性会提升。

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

• 变动引发的风险下降。变动是必然的，若是单一职责原则遵照得好，当修改一个功能时，能够显著下降对其余功能的影响。

难点

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