每種設計模式的出現都是為了彌補語言在某方面的不足，解決特定環境下的問題。思想是相通的。只不過不同的設計語言有其特定的實現。對javascript這種動態語言來說，弱類型的特性，與生俱來的多態性，導致某些設計模式不自覺的我們都在使用。只不過沒有對應起來罷了。本文就力求以精簡的語言去介紹下設計模式這個高大上的概念。相信會在看完某個設計模式之後有原來如此的感慨。

　　一、基本概念與使用場景：

　　基本概念：

　　將請求封裝成對象，分離命令接受者和發起者之間的耦合。 命令執行之前在執行對象中傳入接受者。主要目的相互之間的解耦。簡單而言分為三個對象，

　　1、發起者：發出調用命令即可，具體如何執行，誰執行並不需要清楚。

　　 2、接受者：有對應的接口處理不同的命令，至於命令是什麽，誰發出的，不用關心

　　3、命令對象：上面講發起者和接受者分開了，二者之間需要個連接橋梁。這就是命令對象。命令對象接受發送者的調用，然後調用接受者的相應接口。

　　下面有個簡單的圖表示下三者關系(忽略畫圖技術，要透過現象看本質)：

　　使用場景： 發布一些命令，但不清楚接受者和請求的操作。命令是指執行某些事情的指令。即只用知道發布了一個指令就行，具體做什麽誰來做不用關心。其實是回調函數面向對象的替代品。最常見的例子就是事件綁定了

　　二、實例：

　　　　可能看了上面的內容大家還是感到有點迷糊，當然了只看理論其實很難理解一個東西的。我們下面舉個栗子：

　　　　場景如下：有個按鈕button，點擊之後，調用menu對象的refresh方法，輸出‘refresh’的內容。　　　　

 1 /***
 2  * 非命令模式的綁定事件，就不嚴謹的鞋全部代碼了
 3  * 
 4 */
 5 button.onClick(function (e) {
 6     var menu = {
 7         refresh: function () {
 8             /**
 9              * 執行命令，
10              */
11             console.log(‘refresh‘)
12         }
13     }
14     /**
15      * 發出命令
16     */
17     menu.refresh()
18 })
19 /**
20  * 觸發事件
21 */
22 button.trigger(‘click‘)  
 

　　 這樣寫應該是常用的的寫法，當然menu對象在哪裏定義就隨心情了，都影響不大。如果使用命令模式可以對比一下。我這裏代碼就貼個圖好了(因為是比較早的筆記了，手懶)：

　　簡單分析下這個例子：

　　 一、發送者(setCommond)：不關心給哪個button，以及綁定什麽事件，只要通過參數傳入就好。

　　二、命令對象(commondObj):只需要接收到接受者的參數，當發送者發出命令時，執行就好。

　　三、接受者(menu):不用關心在哪裏被調用被誰調用，只需要按需執行就好了。

　　可能從這一個簡單的例子沒發現命令模式有什麽好處，當然了，設計模式的初衷也不是為了解決簡單問題的。設想，當有n個button，對應不同的接口時。就能看出來差別了，可能按部就班的綁定n多個事件之後。你會發現多寫幾個setCommond(btn,obj)更簡單。

三、結束語：

　　到這裏，設計模式就介紹完了。可能大部分時候我們也這麽做了，只不過你沒有註意到它還有這麽個嚴肅的名稱。

　　重復而言，使用設計模式的目的是為了提高我們解決問題的效率，不同的設計模式也是針對不同環境的特定方案，不僅僅是單獨的某一種設計模式，大多數情況下都是多個模式共存的。切勿為了使用設計模式而強行引入，也切勿不同情況堅持使用某一種設計模式。不要被形式總之快速高效的解決問題才是我們的唯一目的。

參考文章：JavaScript設計模式與開發實踐

javascript設計模式詳解之命令模式