一文詳解前端常用設(shè)計(jì)模式

設(shè)計(jì)模式一直是程序員談?wù)摰摹案叨恕痹掝}之一，總有一種敬而遠(yuǎn)之的心態(tài)。在了解后才知道在將函數(shù)作為一等對(duì)象的語言中，有許多需要利用對(duì)象多態(tài)性的設(shè)計(jì)模式，比如單例模式、 策略模式等，這些模式的結(jié)構(gòu)與傳統(tǒng)面向?qū)ο笳Z言的結(jié)構(gòu)大相徑庭，實(shí)際上已經(jīng)融入到了語言之中，我們可能經(jīng)常使用它們，只是不知道它們的名字而已。

設(shè)計(jì)模式

相信了解的，都知道有 20 多種...

其中按類型分有三種。為“創(chuàng)建型”封裝了創(chuàng)建對(duì)象的變化過程，“結(jié)構(gòu)型”將對(duì)象之間組合的變化封裝，“行為型”則是抽離對(duì)象的變化行為。

接下來，本文將以常用原則中從“單一功能”和“開放封閉”這兩大原則為主線，分別介紹“創(chuàng)建型”、“結(jié)構(gòu)型”和“行為型”中最具代表性的單例、策略、代理、觀察者這幾大設(shè)計(jì)模式。

1 常用原則

這些設(shè)計(jì)原則通常指的是單一職責(zé)原則、里氏替換原則、依賴倒置原則、接口隔離原則、合成復(fù)用原則和最少知識(shí)原則。因?yàn)榘咐猩婕皢我宦氊?zé)原則和開放-封閉原則，所以只介紹這兩部分。

1.1 單一職責(zé)原則(SRP)

一個(gè)對(duì)象(方法)只做一件事情

如果我們有兩個(gè)動(dòng)機(jī)去改寫一個(gè)方法，那么這個(gè)方法就具有兩個(gè)職責(zé)。每個(gè)職責(zé)都是變化的一個(gè)軸線，如果一個(gè)方法承擔(dān)了過多的職責(zé)，那么在需求的變遷過程中，需要改寫這個(gè)方法的可能性就越大。

SRP 原則的優(yōu)點(diǎn)是降低了單個(gè)類或者對(duì)象的復(fù)雜度，按照職責(zé)把對(duì)象分解成更小的粒度， 這有助于代碼的復(fù)用，也有利于進(jìn)行單元測(cè)試。當(dāng)一個(gè)職責(zé)需要變更的時(shí)候，不會(huì)影響到其他的職責(zé)。

但 SRP 原則也有一些缺點(diǎn)，最明顯的是會(huì)增加編寫代碼的復(fù)雜度。當(dāng)我們按照職責(zé)把對(duì)象分解成更小的粒度之后，實(shí)際上也增大了這些對(duì)象之間相互聯(lián)系的難度。

1.2 開放-封閉原則

對(duì)象(類、模塊、函數(shù)等)應(yīng)該是可擴(kuò)展但不可修改的。

就算我們作為維護(hù)者，拿到的是一份混淆壓縮過的代碼也沒有關(guān)系。只要它從前是個(gè)穩(wěn)定運(yùn)行的函數(shù)，那么以后也不會(huì)因?yàn)槲覀兊男略鲂枨蠖a(chǎn)生錯(cuò)誤。新增的代碼和原有的代碼可以井水不犯河水。

2 單例模式

單例模式 （Singleton Pattern）又稱為單體模式，保證一個(gè)類只有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。也就是說，第二次使用同一個(gè)類創(chuàng)建新對(duì)象的時(shí)候，應(yīng)該得到與第一次創(chuàng)建的對(duì)象完全相同的對(duì)象。

2.1 舉個(gè) 登錄彈窗

我們正在開發(fā)一個(gè)網(wǎng)站，網(wǎng)站類型是一個(gè)視頻網(wǎng)站，網(wǎng)站有個(gè)登錄按鈕，點(diǎn)擊登錄會(huì)彈出一個(gè)登錄框進(jìn)行登錄，你現(xiàn)在可能已經(jīng)聯(lián)想到，這個(gè)登錄框一定是頁面唯一的一個(gè) dom 節(jié)點(diǎn)，一個(gè)頁面存在兩個(gè)登錄框是不存在的!

如果要實(shí)現(xiàn)這種效果第一種解決方案就是在頁面加載的時(shí)候就已經(jīng)創(chuàng)建好 dom 節(jié)點(diǎn)，并且設(shè)置樣式為 display 為 none,當(dāng)點(diǎn)擊登錄時(shí)修改為 block 顯示。



這種方式有一個(gè)問題，也許我們進(jìn)入當(dāng)前網(wǎng)站只是玩玩游戲或者看看天氣，根本不需要進(jìn)行登錄操作，因?yàn)榈卿浉〈翱偸且婚_始就被創(chuàng)建好，那么很有可能將白白浪費(fèi)一些 DOM 節(jié)點(diǎn)。所以開始改進(jìn)，當(dāng)我們每次點(diǎn)擊登錄按鈕的時(shí)候，再創(chuàng)建一個(gè)新的登錄浮窗 div。



雖然我們可以在點(diǎn)擊浮窗上的關(guān)閉按鈕時(shí)(此處未實(shí)現(xiàn))把這個(gè)浮窗從頁面中刪除掉，但這樣頻繁地創(chuàng)建和刪除節(jié)點(diǎn)明顯是不合理的，也是不必要的。所以我們?cè)俅芜M(jìn)行改進(jìn)，用一個(gè)變量來判斷是否已經(jīng)創(chuàng)建過登錄浮窗。



這段代碼仍然是違反單一職責(zé)原則（就一個(gè)類(通常也包括對(duì)象和函數(shù)等)而言，應(yīng)該僅有一個(gè)引起它變化的原因）的，創(chuàng)建對(duì)象和管理單例的邏輯都放在 createLoginLayer 對(duì)象內(nèi)部。所以將管理單例的邏輯單獨(dú)提出來。



用于創(chuàng)建登錄浮窗的方法用參數(shù) fn 的形式傳入 getSingle，我們不僅可以傳入 createLoginLayer，還能傳入 createScript、createIframe、createXhr 等。之后再讓 getSingle 返回 一個(gè)新的函數(shù)，并且用一個(gè)變量 result 來保存 fn 的計(jì)算結(jié)果。result 變量因?yàn)樯碓陂]包中，它永遠(yuǎn)不會(huì)被銷毀。在將來的請(qǐng)求中，如果 result 已經(jīng)被賦值，那么它將返回這個(gè)值。

創(chuàng)建實(shí)例對(duì)象的職責(zé)和管理單例的職責(zé)分別放置在兩個(gè)方法里，這兩個(gè)方法可以獨(dú)立變化而互不影響。

所以，在適合的時(shí)候才創(chuàng)建對(duì)象，并且只創(chuàng)建唯一的一個(gè)，如果創(chuàng)建對(duì)象和管理創(chuàng)建單例職責(zé)分布在兩個(gè)不同的方法當(dāng)中，解耦性的加持會(huì)讓這個(gè)模式威力大大增加，這是能提高性能的一個(gè)突破口。

2.2 其他場(chǎng)景

使用場(chǎng)景：Redux、Vuex 等狀態(tài)管理工具，還有我們常用的 window 對(duì)象、全局緩存等。

多次引用只會(huì)使用一個(gè)庫引用，如 jQuery，lodash，moment 等。

Vuex / Redux。Vuex 和 Redux 數(shù)據(jù)保存在單一 store 中，Mobx 將數(shù)據(jù)保存在分散的多個(gè) store 中。

2.3 小結(jié)

在 getSinge 函數(shù)中，實(shí)際上也提到了閉包和高階函數(shù)的概念。單例模式是一種簡(jiǎn)單但非常實(shí)用的模式，考慮在合適的時(shí)候才創(chuàng)建對(duì)象，并且只創(chuàng)建唯一的一個(gè)。創(chuàng)建實(shí)例對(duì)象的職責(zé)和管理單例的職責(zé)分別放置在兩個(gè)方法里，這兩個(gè)方法可以獨(dú)立變化而互不影響。

3 代理模式

代理模式的定義：代理模式給某一個(gè)對(duì)象提供一個(gè)代理對(duì)象，并由代理對(duì)象控制對(duì)原對(duì)象的引用。通俗的來講代理模式就是我們生活中常見的中介。

為什么要使用代理模式

中介隔離作用：在某些情況下，一個(gè)客戶類不想或者不能直接引用一個(gè)委托對(duì)象，而代理類對(duì)象可以在客戶類和委托對(duì)象之間起到中介的作用，其特征是代理類和委托類實(shí)現(xiàn)相同的接口。

開閉原則，增加功能：代理類除了是客戶類和委托類的中介之外，我們還可以通過給代理類增加額外的功能來擴(kuò)展委托類的功能，這樣做我們只需要修改代理類而不需要再修改委托類，符合代碼設(shè)計(jì)的開閉原則。

3.1 舉個(gè) 圖片預(yù)加載

圖片預(yù)加載是一種常用的技術(shù)，如果直接給某個(gè) img 標(biāo)簽節(jié)點(diǎn)設(shè)置 src 屬性， 由于圖片過大或者網(wǎng)絡(luò)不佳，圖片的位置往往有段時(shí)間會(huì)是一片空白。常見的做法是先用一張 loading 圖片占位，然后用異步的方式加載圖片，等圖片加載好了再把它填充到 img 節(jié)點(diǎn)里，這種場(chǎng)景就很適合使用虛擬代理。



但這里可以看到 MyImage 這個(gè)對(duì)象承擔(dān)了多項(xiàng)職責(zé)，就意味著這個(gè)對(duì)象將變得巨大，引起它變化的原因可能會(huì)有 2 個(gè)。當(dāng)系統(tǒng)需求發(fā)生改變時(shí)，盡量不修改系統(tǒng)原有代碼功能，應(yīng)該擴(kuò)展模塊的功能，來實(shí)現(xiàn)新的需求。

所以 5 年后的網(wǎng)速快到根本不再需要預(yù)加載，我們可能希望把預(yù)加載圖片的這段代碼從 MyImage 對(duì)象里刪掉。這時(shí)候就不得不改動(dòng) MyImage 對(duì)象了。所以對(duì)于上述代碼進(jìn)行優(yōu)化。



這里通過 proxyImage 間接地訪問 MyImage。proxyImage 控制了客戶對(duì) MyImage 的訪問，并且在此過程中加入一些額外的操作，比如在真正的圖片加載好之前，先把 img 節(jié)點(diǎn)的 src 設(shè)置為 一張本地的 loading 圖片，避免了在圖片被加載好之前，頁面中有一段長(zhǎng)長(zhǎng)的空白時(shí)間。

實(shí)際上，我們需要的只是給 img 節(jié)點(diǎn)設(shè)置 src，預(yù)加載圖片只是一個(gè)錦上添花的功能。如果 能把這個(gè)操作放在另一個(gè)對(duì)象里面，自然是一個(gè)非常好的方法。于是代理的作用在這里就體現(xiàn)出 來了，代理負(fù)責(zé)預(yù)加載圖片，預(yù)加載的操作完成之后，把請(qǐng)求重新交給本體 MyImage。既滿足了單一職責(zé)原則，又滿足了開放封閉原則。

3.2 再舉個(gè) 合并請(qǐng)求

在 Web 開發(fā)中，也許最大的開銷就是網(wǎng)絡(luò)請(qǐng)求。假設(shè)我們?cè)谧鲆粋€(gè)文件同步的功能，當(dāng)我們選中一個(gè) checkbox 的時(shí)候，它對(duì)應(yīng)的文件就會(huì)被同步到另外一臺(tái)備用服務(wù)器上面，如圖所示。

我們先在頁面中放置好這些 checkbox 節(jié)點(diǎn)，接下來，給這些 checkbox 綁定點(diǎn)擊事件，并且在點(diǎn)擊的同時(shí)往另一臺(tái)服務(wù)器同步文件。



當(dāng)我們選中 3 個(gè) checkbox 的時(shí)候，依次往服務(wù)器發(fā)送了 3 次同步文件的請(qǐng)求。而點(diǎn)擊一個(gè) checkbox 并不是很復(fù)雜的操作，但如果有 100 個(gè)文件，1w 個(gè)文件，可以預(yù)見，如此頻繁的網(wǎng)絡(luò)請(qǐng)求將會(huì)帶來相當(dāng)大的開銷。

解決方案是，我們可以通過一個(gè)代理函數(shù) proxySynchronousFile 來收集一段時(shí)間之內(nèi)的請(qǐng)求，最后一次性發(fā)送給服務(wù)器。比如我們等待 2 秒之后才把這 2 秒之內(nèi)需要同步的文件 ID 打包發(fā)給服務(wù)器，如果不是對(duì)實(shí)時(shí)性要求非常高的系統(tǒng)，2 秒的延遲不會(huì)帶來太大副作用，卻能大大減輕服務(wù)器的壓力。



3.3 小結(jié)

縱觀圖片預(yù)加載整個(gè)程序，我們并沒有改變或者增加 MyImage 的接口，但是通過代理對(duì)象，實(shí)際上給系統(tǒng)添加了新的行為。這是符合開放—封閉原則的。給 img 節(jié)點(diǎn)設(shè)置 src 和圖片預(yù)加載這兩個(gè)功能，被隔離在兩個(gè)對(duì)象里，它們可以各自變化而不影響對(duì)方。何況就算有一天我們不再需要預(yù)加載，那么只需要改成請(qǐng)求本體而不是請(qǐng)求代理對(duì)象即可。

代理類主要負(fù)責(zé)為委托類預(yù)處理消息、過濾消息、把消息轉(zhuǎn)發(fā)給委托類，以及事后對(duì)返回結(jié)果的處理等。代理類本身并不真正實(shí)現(xiàn)服務(wù)，而是同過調(diào)用委托類的相關(guān)方法，來提供特定的服務(wù)。真正的業(yè)務(wù)功能還是由委托類來實(shí)現(xiàn)，但是可以在業(yè)務(wù)功能執(zhí)行的前后加入一些公共的服務(wù)。例如我們想給項(xiàng)目加入緩存、日志這些功能，我們就可以使用代理類來完成，而沒必要打開已經(jīng)封裝好的委托類。

雖然代理模式非常有用，但我們?cè)诰帉憳I(yè)務(wù)代碼的時(shí)候，往往不需要去預(yù)先猜測(cè)是否需要使用代理模式。當(dāng)真正發(fā)現(xiàn)不方便直接訪問某個(gè)對(duì)象的時(shí)候，再編寫代理也不遲。

4 策略模式

該模式定義了一系列算法，并將每個(gè)算法封裝起來，使它們可以相互替換，且算法的變化不會(huì)影響使用算法的客戶。

4.1 舉個(gè) 多條件業(yè)務(wù)

多業(yè)務(wù)場(chǎng)景下的訂單跳轉(zhuǎn)一直是個(gè)很頭疼的問題，因?yàn)槊織l業(yè)務(wù)的訂單可能需要定制，跳轉(zhuǎn)的詳情也可能不太一樣，當(dāng)業(yè)務(wù)線過多的時(shí)候，很容易陷入多重條件地獄，不斷去累加判斷條件。

如上這種，雖然是看起來?xiàng)l件很多但是屬于單條件，我們可以使用策略模式來簡(jiǎn)單改造，如下所示：



但是我們的業(yè)務(wù)可能會(huì)更加復(fù)雜，訂單頁面我們采用了 h5 嵌入其他應(yīng)用的模式，我們可能將此業(yè)務(wù)嵌入快應(yīng)用、RN、原生 App、小程序、h5 等各種環(huán)境里面，展示的內(nèi)容以及路由跳轉(zhuǎn)可能都不盡相同，我們?yōu)榱嗽黾与y度，更為直觀的體現(xiàn)，所以每種對(duì)應(yīng)的規(guī)則都默認(rèn)是完全不同的方法。



看到上述代碼，可能人生已經(jīng)絕望，因?yàn)閷?shí)際中的訂單類型遠(yuǎn)不止 3 種，環(huán)境類型也遠(yuǎn)不止 3 種，然而還可能有更多的附件條件并沒有加上去。且越來越多的條件加入的同時(shí)，造成代碼的可讀性、可維護(hù)性、可迭代性急速下降，雖然上述代碼格式化之后，看起來倒還是很工整的。

雖然上述是多重嵌套條件，但拆分開來還是可以理解為訂單類型跟環(huán)境類型的組合，我們借助 es6 map 對(duì)象來進(jìn)行改造。



如上述重構(gòu)后的，我們借助 map 對(duì)象的特性（此處不對(duì) map 對(duì)象做更深的拓展講解）。如果再有新增的規(guī)則，我們可以放在 map 里面進(jìn)行新增對(duì)應(yīng)規(guī)則與方法，減少條件嵌套地獄出現(xiàn)，并且邏輯會(huì)更加清晰。但實(shí)際情況中還可以對(duì)類似的方法進(jìn)行合并，邏輯會(huì)更加清晰。

4.2 再舉個(gè) 表單校驗(yàn)

在一個(gè) Web 項(xiàng)目中，注冊(cè)、登錄、修改用戶信息等功能的實(shí)現(xiàn)都離不開提交表單。

在將用戶輸入的數(shù)據(jù)交給后臺(tái)之前，常常要做一些客戶端力所能及的校驗(yàn)工作，比如注冊(cè)的時(shí)候需要校驗(yàn)是否填寫了用戶名，密碼的長(zhǎng)度是否符合規(guī)定等等。這樣可以避免因?yàn)樘峤徊缓戏〝?shù)據(jù)而帶來的不必要網(wǎng)絡(luò)開銷。

假設(shè)我們正在編寫一個(gè)注冊(cè)的頁面，在點(diǎn)擊注冊(cè)按鈕之前，有如下幾條校驗(yàn)邏輯。

用戶名不能為空。

密碼長(zhǎng)度不能少于 6 位。

手機(jī)號(hào)碼必須符合格式。

傳統(tǒng)編寫表單校驗(yàn)

這是一種很常見的代碼編寫方式，它的缺點(diǎn)有以下。

registerForm.onsubmit 函數(shù)比較龐大，包含了很多 if-else 語句，這些語句需要覆蓋所有的校驗(yàn)規(guī)則。

registerForm.onsubmit 函數(shù)缺乏彈性，如果增加了一種新的校驗(yàn)規(guī)則，或者想把密碼的長(zhǎng)度校驗(yàn)從 6 改成 8，我們都必須深入 registerForm.onsubmit 函數(shù)的內(nèi)部實(shí)現(xiàn)，這是違反開放—封閉原則的。

算法的復(fù)用性差，如果在程序中增加了另外一個(gè)表單，這個(gè)表單也需要進(jìn)行一些類似的校驗(yàn)，那我們很可能將這些校驗(yàn)邏輯復(fù)制得漫天遍野。

下面我們將用策略模式來重構(gòu)表單校驗(yàn)的代碼，很顯然第一步我們要把這些校驗(yàn)邏輯都封裝成策略對(duì)象。



4.3 小結(jié)

通過使用策略模式重構(gòu)代碼，我們消除了原程序中大片的條件分支語句，代碼變得更加清晰，各個(gè)類的職責(zé)更加鮮明。一般策略對(duì)象往往被函數(shù)所代替，這時(shí)策略模式就成為一種“隱形”的模式。把這些校驗(yàn)邏輯都封裝成策略對(duì)象，也可以復(fù)用在系統(tǒng)的其他地方，從而避免許多重復(fù)的復(fù)制粘貼工作。

5 觀察者模式

觀察者模式建立了一套觸發(fā)機(jī)制，幫助我們完成更松耦合的代碼編寫。

它定義對(duì)象間的一種一對(duì)多的依賴關(guān)系，當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí)，所有依賴于它的對(duì)象都將得到通知。

5.1 舉個(gè) 網(wǎng)站登錄

假如我們正在開發(fā)一個(gè)商城網(wǎng)站，網(wǎng)站里有 header 頭部、nav 導(dǎo)航、消息列表、購物車等模塊。這幾個(gè)模塊的渲染有一個(gè)共同的前提條件，就是必須先用 ajax 異步請(qǐng)求獲取用戶的登錄信息。這是很正常的，比如用戶的名字和頭像要顯示在 header 模塊里，而這兩個(gè)字段都來自用戶登錄后返回的信息。



現(xiàn)在登錄模塊是我們負(fù)責(zé)編寫的，但我們還必須了解 header 模塊里設(shè)置頭像的方法叫 setAvatar、購物車模塊里刷新的方法叫 refresh，這種耦合性會(huì)使程序變得僵硬，header 模塊不能隨意再改變 setAvatar 的方法名，它自身的名字也不能被改為 header1、header2。

等到有一天，項(xiàng)目中又新增了一個(gè)收貨地址管理的模塊，這個(gè)模塊本來是另一個(gè)同事所寫的， 而此時(shí)你正在度假，但是他卻不得不給你打電話:“Hi，登錄之后麻煩刷新一下收貨地址列表。”于是你又翻開你 3 個(gè)月前寫的登錄模塊，在最后部分加上這行代碼。



用觀察者模式重寫之后，對(duì)用戶信息感興趣的業(yè)務(wù)模塊將自行訂閱登錄成功的消息事件。當(dāng)?shù)卿洺晒r(shí)，登錄模塊只需要發(fā)布登錄成功的消息，而業(yè)務(wù)方接受到消息之后，就會(huì)開始進(jìn)行各自的業(yè)務(wù)處理，登錄模塊并不關(guān)心業(yè)務(wù)方究竟要做什么，也不想去了解它們的內(nèi)部細(xì)節(jié)。



我們隨時(shí)可以把 setAvatar 的方法名改成 setTouxiang。如果有一天在登錄完成之后，又增加一個(gè)刷新收貨地址列表的行為，那么只要在收貨地址模塊里加上監(jiān)聽消息的方法即可。

5.2 小結(jié)

觀察者模式的優(yōu)點(diǎn)非常明顯，一為時(shí)間上的解耦，二為對(duì)象之間的解耦。它的應(yīng)用非常廣泛，既可以用在異步編程中，也可以幫助我們完成更松耦合的代碼編寫。但是創(chuàng)建訂閱者本身要消耗一定的時(shí)間和內(nèi)存，而且當(dāng)你訂閱一個(gè)消息后，也許此消息最后都未發(fā)生，但這個(gè)訂閱者會(huì)始終存在于內(nèi)存中。另外，觀察者模式雖然可以弱化對(duì)象之間的聯(lián)系，但如果過度使用的話，對(duì)象和對(duì)象之間的必要聯(lián)系也將被深埋在背后，會(huì)導(dǎo)致程序難以跟蹤維護(hù)和理解。

6 總結(jié)

烹飪有菜譜，游戲有攻略，干啥都有一些能夠讓我們達(dá)到目標(biāo)的“套路”，在程序世界，編程的“套路”就是設(shè)計(jì)模式。

前端常用的設(shè)計(jì)模式出從單例、代理、策略、觀察者模式入手，帶大家去了解設(shè)計(jì)模式的核心操作是去觀察你整個(gè)邏輯里面的變與不變，然后將變與不變分離，達(dá)到使變化的部分靈活、不變的地方穩(wěn)定的目的。在我們遇到相似的問題、場(chǎng)景時(shí)，能快速找到更優(yōu)的方式解決。

審核編輯：劉清