前端 JS 設計模式之狀態模式和其它設計模式

一、狀態模式

1. 狀態模式，一個對象有狀態變化。每次狀態變化都會觸發一個邏輯，不能總是用 if-else 來控制。
2. 對於狀態模式的理解，可以舉一個例。比如在十字路口的時候，交通信號燈不同顏色的變化，會有其相應的指示命令。
3. 對於狀態模式的場景，比如有限狀態機、一個簡單的 Promise 等等。有限狀態機是有限個狀態，以及在這些狀態之間的變化，比如交通燈。
4. 狀態模式的設計原則驗證，將狀態對象和主題對象分離，狀態的變化邏輯單獨處理，符合開放封閉原則。
5. 狀態模式的代碼，如下所示：

// 狀態
class State {
    constructor(color) {
        this.color = color
    }
    handle(context) {
        console.log(`turn to ${this.color} light`)
        context.setState(this)
    }
}

// 主體
class Context {
    constructor() {
        this.state = null
    }
    setState(state) {
        this.state = state
    }
    getState() {
        return this.state
    }
}

// 測試代碼
let context = new Context()

let greed = new State('greed')
let yellow = new State('yellow')
let red = new State('red')

// 綠燈亮了
greed.handle(context)
console.log(context.getState())
// 黃燈亮了
yellow.handle(context)
console.log(context.getState())
// 紅燈亮了
red.handle(context)
console.log(context.getState())

二、原型模式

1. 原型模式，clone 自己，生成一個新對象。java 默認有 clone 接口，不用自己實現。
2. 對比 JS 中的原型 prototype，prototype 可以理解爲 ES6 class 的一種底層原理，而 class 是實現面向對象的基礎，並不是服務於某個模式。若干年後 ES6 普及，可能會忽略掉 prototype，但是 Object.create 是會永久存在的。

三、橋接模式

1. 橋接模式，用於把抽象化與實現化解耦，使得二者可以獨立變化。
2. 橋接模式的設計驗證原則，抽象和實現分類，解耦，符合開放封閉原則。

四、組合模式

1. 組合模式，生成樹形結構，表示整體與部分的關係，讓整體和部分都具有一致的操作方式。
2. 對於組合模式的場景應用，在虛擬 DOM 中的 vnode 是這種形式，但是數據類型簡單。
3. 對於組合模式，整體和單個節點的操作是一致的，整體和單個節點的數據結構也保持一致。
4. 組合模式的設計原則驗證，將整體和單個節點的操作抽象出來，符合開放封閉原則。

五、享元模式

1. 享元模式，共享內存，主要考慮的是內存，而非效率。相同的數據，共享使用。
2. 享元模式的設計原則驗證，將相同的部分抽象出來，符合開放封閉原則。

六、策略模式

1. 策略模式，不同策略分開處理，避免出現大量的 if...else 或者 switch...case。
2. 策略模式的設計原則驗證，不同策略，分開處理，而不是混合在一起，符合開放封閉原則。

七、模版方法模式和職責連模式

1. 模版方法模式，通過一個模版封裝起來，調用的時候就可以直接使用。
2. 職責連模式，一步操作可能分位多個職責角色來完成，把這些角色都分開，然後用一個鏈串起來，將發起者和各個處理者進行隔離。
3. JS 的鏈式操作，職責鏈模式和業務結合較多，JS 中能聯想到鏈式操作。jQuery 的鏈式操作，Promise.then 的鏈式操作。
4. 職責連模式的設計原則驗證，發起者於各個處理者進行隔離，符合開放封閉原則。

八、命令模式

1. 命令模式，執行命令時，發佈者和執行者分開。中間加入命令對象，作爲中轉站。
2. 對於命令模式，發送者發出命令，調用命令對象，命令對象接收命令，調用接受者對應接口。
3. 對於命令模式在 JS 中的應用，網頁富文本編輯器操作，瀏覽器封裝了一個命令對象。
4. 命令模式的設計原則驗證，命令對象於執行對象分開，解耦，符合開放封閉原則。

九、備忘錄模式

1. 備忘錄模式，隨時記錄一個對象的狀態變化，隨時可以恢復之前的某個狀態，比如撤銷功能。
2. 備忘錄模式的設計原則驗證，狀態對象於使用者分開，解耦，符合開放封閉原則。

十、中介者模式

1. 中介者模式，如果有很多個對象之間相互存在依賴關係，這個時候可以用中介者去管理，各個對象與中介者之間進行聯繫。
2. 中介者模式的設計原則驗證，將各個關聯對象通過中介者隔離，符合開放封閉原則。

十一、訪問者模式和解釋器模式

1. 訪問者模式， 將數據操作和數據結構進行分離，使用場景不多。
2. 解釋器模式，描述語言語法如何定義，如何解釋和編譯，用於專業場景。