『面試的底氣』—— 設計模式之單一職責原則｜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方法。

以上說到了租客不多是一我的，那麼職責中不可能只有單獨一個方法，甚至職責還會包含其餘子職責。那麼如何把衆多功能分別歸屬到對應的職責中，還有如何劃分職責，就是架構設計時要考慮的事情了。

單一職責原則不僅僅只應用在類中，也能夠應用在普通函數中，即一個函數只處理一件事件。

做用及優勢

單一職責原則的做用是控制類的粒度大小、將對象解耦、提升其內聚性。其有如下優勢：

• 下降類的複雜度。一個類只負責一項職責，其邏輯確定要比負責多項職責簡單得多。

• 提升類的可讀性。複雜性下降，天然其可讀性會提升。

• 提升代碼的可維護性。可讀性提升，那天然更容易維護了。

• 變動引發的風險下降。變動是必然的，若是單一職責原則遵照得好，當修改一個功能時，能夠顯著下降對其餘功能的影響。

難點

遵循單一職責原則的過程當中，最大的難點就是職責如何劃分，劃分過細，會致使類過多，也會致使維護困難，劃分過粗，可能會違背單一職責原則。