設計模式-行爲型-命令模式（COMMAND）

　　命令模式是一個結構比較簡單的設計模式，gof在書中對它的定義是：「將一個請求封裝爲一個對象，從而使你可用不一樣的請求對客戶進行參數化；對請求排隊或記錄請求日誌，以及支持可撤消的操做。」

　　這裏有兩個要點，第一請求被封裝成了一個對象，第二請求能夠被持久化（排隊或是記錄、取消）。

　　咱們從第一個要點提及。首先須要注意一點的全部COMMAND的模型均可以抽象出一個Execute概念或是相似概念。以下圖（左）同樣，這裏的請求就是對文檔作出paste操做，封裝的結果就是經過PasteCommand的一個對象就能完成對一個特定document的操做，這個特定的document可能在構建這個PasteCommand對象時建立的，或者是在之後的使用中經過PasteCommand對象的成員變量設置的，不一而足，這全取決於你的實現。這樣本來應該是一個函數作的事情變成了一個對象。乍一看彷彿這樣的操做是畫蛇添足，可是咱們回憶一下工廠模式裏面提到的關於提出「工廠」這個抽象的好處，其中一個就是給程序帶來了一個子類掛鉤，這樣能夠將全部關於該請求的可能變化推遲到了command子類對象，一方面大大提升了程序的可讀性也知足的開閉設計原則。下圖（右）的例子就很好的說明了把請求封裝成對象帶給咱們的直接好處。

                        

　　接下來咱們看看，請求能夠被持久化。第一點咱們看到因爲新增了一個子類掛鉤，給整個設計增長了很大的拓展性，全部的業務邏輯均可以封裝到子類。同時由於新增了子類層次，子類對象也能夠管理本身的狀態，這種狀態能夠體如今調用對象，既是請求的記錄上。由於有了子類層次，讓這類信息的獲取就直接轉換成了經過子類對象的成員函數獲取子類對象的狀態這樣的問題。

　　回顧一下上一個責任鏈模式的結構圖。細心的讀者會發現下圖的藍框裏面的結構很像的命令模式，全部ConcreteHandler均可以被看做是一個COMMAND,全部的COMMAND共享一個概念HandleRequest，這個概念相似於Command的Execute。gof的書中提到了COMMAND於COMPOSITE的密切聯繫，CHAIN OF RESPONSIBILITY於COMPOSITE的密切聯繫。單單漏掉了CHAIN OF RESPONSIBILITY與COMMAND的聯繫，爲何呢？ 就筆者的理解，CHAIN OF RESPONSIBILITY跟COMMAND，他們直接的關係就像是BUILDER與FACTORY METHOD同樣，只有有形式上的聯繫。咱們能夠注意到兩個設計模式的定義，CHAIN OF RESPONSIBILITY強調了一樣的請求被傳遞到不動的處理節點，可是COMMAND模式則是轉換請求爲一個對象，一個是請求傳遞，一個是請求轉換。全部根本上兩個模式的設計目的是不一樣的。那麼這個設計模式在現實當中有用處嗎？筆者注意到C++11標準或是boost庫中的thread類，將對執行流的要求轉換成了對thread對象的調用，只是thread類沒有實現請求持續化的要求，thread類有的是保存了執行流的狀態。可是不妨礙它把請求轉換成對象的事實，全部筆者認爲thread類就是一個弱化的command模式。