最近看了同事的代碼，感覺甚是優(yōu)雅病毡，再看看自己的濒翻，不禁自慚形穢，為了提高代碼的可擴(kuò)展性和可維護(hù)性等啦膜，是時(shí)候好好學(xué)習(xí)一下設(shè)計(jì)模式了有送。在學(xué)習(xí)設(shè)計(jì)模式之前，需要先看一下設(shè)計(jì)原則僧家，因?yàn)樵O(shè)計(jì)原則是核心思想雀摘。就好比練劍，設(shè)計(jì)原則是心訣要領(lǐng)啸臀，設(shè)計(jì)模式是招式届宠。
我們常說的SOLID原則，是包括單一職責(zé)原則乘粒、開閉原則、里式替換原則伤塌、接口隔離原則和依賴反轉(zhuǎn)原則這五個(gè)灯萍，與五個(gè)英文字母一一對(duì)應(yīng)。 今天每聪，就先來看一下單一職責(zé)原則旦棉。
什么是單一職責(zé)原則呢齿风？
英文：Single Responsibility Principle，縮寫SRP绑洛。英文描述：A class or module should have a single reponsibility.(一個(gè)類或模塊只負(fù)責(zé)完成一個(gè)功能)
這個(gè)定義很好理解救斑，比如我們開發(fā)的時(shí)候要實(shí)現(xiàn)一個(gè)filter組件，不僅實(shí)現(xiàn)了搜索的功能真屯，還把搜索之后的行為定義了出來脸候，例如把搜索結(jié)果作為參數(shù)發(fā)送請(qǐng)求。搜索和發(fā)送請(qǐng)求是兩個(gè)不同的功能绑蔫，再說搜索之后不一定是發(fā)送請(qǐng)求运沦，還可能是其他的行為，這就影響了組件的復(fù)用性配深，違反了單一職責(zé)原則携添。
所以對(duì)于類或模塊或者函數(shù)等，不要設(shè)計(jì)的大而全篓叶，盡量粒度小烈掠、功能單一，只包含一個(gè)職責(zé)缸托。如果包含多個(gè)職責(zé)左敌，在需求變更的過程中，就有可能因?yàn)樾薷钠渲幸粋€(gè)職責(zé)而引起其他職責(zé)出現(xiàn)bug嗦董。
如何看類或方法是否滿足單一職責(zé)原則呢母谎？
單一職責(zé)原則理解起來很簡單，我們都知道啥意思京革，但在具體應(yīng)用中還是有些難度的奇唤。不同的應(yīng)用場景、需求階段匹摇、業(yè)務(wù)層面咬扇，對(duì)同一個(gè)類的職責(zé)是否單一，可能會(huì)有不同的判定結(jié)果廊勃。
下面通過一個(gè)例子讓我們一起來學(xué)習(xí)一下懈贺。就拿疫情期間學(xué)生上網(wǎng)課來說吧，StudentInfo類大致會(huì)包含以下字段：
class StudentInfo {
private name: string; // 姓名
private age: number; // 年齡
private class: string; // 班級(jí)
private date: string; // 上課日期
private onlineStartTime: string; // 網(wǎng)課開始時(shí)間
private onlineEndTime: string; // 網(wǎng)課結(jié)束時(shí)間
private province; // 省
private city; // 市
private region; // 地區(qū)
private detailedAddress; // 詳細(xì)地址
}
上面的這些字段能否都?xì)w屬于StudentInfo類呢坡垫？它符不符合單一職責(zé)原則呢梭灿？如果初始這個(gè)系統(tǒng)很簡單，所有的信息都只是用來展示而已冰悠，那都放到一起也沒有問題堡妒，因?yàn)樗鼈円泊_實(shí)都是學(xué)生的信息。后來有了新的需求溉卓，老師想看一看各個(gè)班級(jí)學(xué)生的網(wǎng)課情況皮迟，由于要對(duì)網(wǎng)課相關(guān)的信息做更多的處理搬泥，就可以把date、onlineStartTime伏尼、onlineEndTime字段拆分出來忿檩，獨(dú)立成一個(gè)類。經(jīng)過對(duì)網(wǎng)課情況的分析爆阶，發(fā)現(xiàn)有些學(xué)生經(jīng)常網(wǎng)課遲到燥透，那是不是某些地區(qū)網(wǎng)絡(luò)不好等情況影響的啊，這就需要地址信息做更多的分析操作扰她，也就可以把地址信息單獨(dú)拆分出來兽掰。
所以，在不同的需求階段或不同的業(yè)務(wù)背景應(yīng)用場景下徒役，對(duì)一個(gè)類是否職責(zé)單一的判定也是不同的孽尽。我們可以根據(jù)對(duì)業(yè)務(wù)的理解程度，預(yù)測之后可能會(huì)有哪些功能忧勿，來設(shè)計(jì)職責(zé)單一的類或模塊杉女。但很多時(shí)候我們無法預(yù)測之后的需求走向，這時(shí)可以先寫粗粒度的類鸳吸，之后根據(jù)需求變更再不斷重構(gòu)熏挎，畢竟重構(gòu)也是開發(fā)的一部分，可以讓代碼保持可讀性晌砾、可維護(hù)性坎拐、可擴(kuò)展性等。
現(xiàn)在我們知道判斷類是否職責(zé)單一是一個(gè)很靠感覺的東西养匈，不像算法題有固定的解法哼勇，這也是它在實(shí)施的過程中比較困難的地方。我在《設(shè)計(jì)模式之美》專欄中看到了王爭老師給出的一些判斷指標(biāo)很具有指導(dǎo)意義呕乎，出現(xiàn)下面的情況就可能說明類的設(shè)計(jì)不滿足單一職責(zé)原則：
- 類中的代碼行數(shù)积担、函數(shù)或?qū)傩赃^多，會(huì)影響代碼的可讀性和可維護(hù)性
- 類依賴的其他類過多猬仁，或依賴類的其他類過多帝璧，不符合高內(nèi)聚、低耦合的思想
- 私有方法過多湿刽，就要考慮能否將私有方法獨(dú)立到新的類中的烁，設(shè)置為public，供更多的類使用诈闺，提高代碼復(fù)用性撮躁。
- 比較難給類起一個(gè)合適的名字，很難用一個(gè)業(yè)務(wù)名詞概括买雾，或只能用籠統(tǒng)的詞語來命名把曼，就說明類的職責(zé)可能不夠清晰
- 類中大量的方法都是集中操作類的某幾個(gè)屬性，就可以考慮將這幾個(gè)屬性和對(duì)應(yīng)的方法拆分出來漓穿。
為了滿足單一職責(zé)原則嗤军，是不是要把方法或類設(shè)計(jì)的越單一越好呢？
大家都聽說過“過猶不及”這個(gè)詞晃危，什么事都得有個(gè)度叙赚，如果為了追求單一職責(zé)原則而過度拆分，也會(huì)影響代碼的可讀性和可維護(hù)性僚饭。
不管使用什么設(shè)計(jì)原則和模式震叮，提高代碼的可讀性、可維護(hù)性鳍鸵、可擴(kuò)展性苇瓣、復(fù)用性，使代碼高內(nèi)聚偿乖、低耦合才是目的击罪。
