程式設計師必備設計模式之命令模式

國慶假期最後一天了，今天我們再來講一個設計模式，命令模式。這個模式，相信各位程式設計師朋友都曾經使用過，只是你還有可能沒有理解它的核心思想。

這幾年隨著物聯網越來越發達，這種場景越來越常見了，我們可以透過語音來控制全家的家電，小米、華為、阿里跟百度，都是在這方面做得比較好的，透過一個智慧音箱或者智慧手機，可以隨便開啟電視，開關空調等等。那麼，你有沒有想過這麼一個問題，為什麼這些物聯網的智慧中心知道如何去關閉你家的智慧裝置呢？在程式碼上應該是什麼樣的架構，如何進行設計呢？

我們我們知道，市面上的智慧裝置非常多，廠商也非常多，每個廠商可能的標準都不一樣，如果我們來開發一個物聯網智慧中心，我們不可能去學習所有廠商的API介面，學習他們的程式碼，一來成本非常地高，二來實現起來非常的複雜，即使是同一個廠商，可能不同的裝置都有不同的邏輯，開發成本巨大。

這個時候就要祭出我們的設計模式了，命令模式。命令模式是一種資料驅動的設計模式，它屬於行為型模式。它將請求封裝成物件，執行者不用關心裡面的具體實現邏輯，只要進行執行就可以了。在現在的物聯網開放平臺上，也是這麼實現的，廠商去對應的開放平臺上，申請一個命令，編寫相應的程式碼，至於物聯網智慧中心，它並不關心具體的程式碼實現，只知道你家的智慧空調綁定了這個命令，直接使用這個命令即可。

可能到這裡你還有點懵，這講得都是什麼玩意。我們再透過一個耳熟能詳的例子。相信大家都有使用過執行緒池的使用經驗。無論是JAVA也好，C++也好，大多數的執行緒池都是這樣使用的。你建立一個類，去實現某一個介面，例如Java中的Runnable。然後你就可以將這個類放入執行緒池的隊列當中了。

這實際上就是一個典型的命令模式，對於執行緒池來說，只關心執行緒的排程，佇列的大小，執行緒數量這些，不用關心具體舉行的任務，只知道呼叫對應的執行方法即可。對於命令本身，只關心自身的邏輯，不用關心執行緒如何排程。這就非常好的將命令的請求者與命令的執行者進行解耦了！

總結

好了，今天我們學習了命令模式，是不是很親切，原來我們一直都在使用！歡迎大家關注我，共同學習，共同進步。大家的支援是我繼續嘮嗑的動力。