[設計模式篇] 命令模式

標籤：

我時常以為，所謂的“設計模式”，更多像是一種方法論，而不應該算作所謂的“知識點”。這些就像高中數學有專門的解題方法集合，形如“不等式逼等式”（證明一個未知數大於等於一個值，同時又證明這個未知數小於等於這個值，那麼這個未知數只能是這個值）這樣的方法一般，根本沒法說得非常具體。而這才是所謂“知識”大放異彩的地方，沒有這些無數人總結出來的具體的方法，讓我們通過個人總結對現有的知識點進行連結來形成一套，哪怕只是一個小小的方法，或者模式，都是很難得的。如果將學高中數學的方法論做一個合理的外推，那麼程式設計中也就像是用一些知識點（一門或多門變成語言）來串接起來解決一個問題，在解決問題的過程中，通過一系列方法（模式）的運用，來獲得一個最佳實務，也可以說是數學難題給出的推薦答案。但程式設計與數學難題不同的地方在於，數學難題的某些步驟可以暫時跳過，或者說，即使你沒有完全解出題目，也可以完成你暫時明了的工作，而程式設計是一個“非1即0”的過程，“what you see is what you get”，一個小小的錯誤，往往可以拖崩整個程式，哪怕只是百分之一的錯誤，也完全可以讓已完成的百分之九十九毫無價值。好在作為一個學習者，目前碰到的問題，往往都有以往的解決方案提供，簡言之，因為菜，所以先專註於積累，等到你真的拆了千萬輪子，見過各種實現，可以揮灑自如時，自然可以寫出自己的感悟，那種高度不知比初學時的鑽牛角尖高了多少個level！

命令模式（Command Pattern）,在gof中的定義是這樣的“Encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests, and the queuing or logging of requests. It also allows for the support of undoable operations.”沒錯，“將請求分裝成對象，然後用不同的請求，隊列或日誌來參數化對象，同時也支援可撤銷的操作”，這裡的重點在於“請求”的封裝，正如我在上文所提，所有的設計模式（解決方案）都是應用於具體問題的解決過程的，我們參考Head First的案例，開始我們的故事。

假設我們現在要設計一個遙控器，這個遙控器具有多個可程式化的插槽，我們希望每一個插槽都能控制一個或一組家電裝置（電視，電燈，音響啥的），每一個插槽都對應有一個開關，同時還有一個總的撤銷（undo）按鈕來進行退回，怎麼來設計這個遙控器呢？

這個問題的痛點在於，每一個特定的家電裝置，其所謂開關都是不一樣的，比如電視就是簡單的開關，而風扇則涉及到風速的大小（想想我們平時的風扇，開/風速都是設計到一個按鈕上），音響就涉及到立體聲啊，低重音啊之類的開關... ...在我們這個遙控器中，每一個開關按下去，往往會產生一系列的措施，然而對於我們的遙控器來說，它根本不需要知道這些實現的細節，只要知道，我有一個關於“開啟風扇”的“請求”過來，我就執行，即把我們的請求封裝成一個特定的對象，當按鈕按下時，就可以請求對象來做相關的工作，然後故事就結束了，風扇這個對象和遙控器就這麼解耦了，將“動作的執行者”和“動作的要求者”解耦，也就是命令模式的精髓所在。

那麼怎麼來做呢？我們設計一個Command借口，其只有一個方法，execute（），對應我們的風扇，我們通過一個FanHighCommand來實現這個介面，表示已高速來開啟風扇。然後，我們寫一個遙控器remote，它有一個setCommand方法和一個buttonWasPressed方法，前者用來設定那個方法，後者表示調用方法。這裡可以看出命令模式的思想，也就是，這個遙控器壓根就不管command是什麼，只要將command封裝傳進來，然後就執行即可，至於執行的過程，寫在的繼承自command的方法裡（比如這裡我們把高速開啟風的過程的實現寫在了FanHighCommand裡）；

當要進行一些列操作時（比如一鍵“轟趴模式”），我們只要將這一系列的執行過程（音響開，低重音起，燈光暗淡，TV開）分別寫進每一個電器的執行過程中，然後將這一系列的command封裝好未一個HomePartyCommand，傳染remote的setCommand中，就可以一鍵轟趴，有木有比較炫？undo的實現其實比較簡單，讀者可以自己想想怎麼弄。

話說回來，筆者的代碼經驗還是太少，幾乎沒有用過命令模式，這種將運算快打包傳來傳去的方法，似乎用在“隊列請求”或“日誌請求”中比較合適，一個一個調用，執行只管execute，壓根就不管具體怎麼玩，是一種不錯的解耦吧！

[設計模式篇] 命令模式