模式雖然精妙，卻難完美，比如觀察者模式中觀察者生命周期的問題；比如訪問者模式中循環依賴的問題等等；其它很多模式也存在這樣那樣的一些不足之處，如使用場景受限、實現復雜、不夠簡潔、不夠通用等。但我覺得不足之處大都是可以采取一些手法去彌補去改進的，比如用c++11的新特性來改進。因此，便有了c++11改進我們的模式這個系列。這次我要講的是如何使用c++11改進命令模式。關于命令模式

　　命令模式的作用是將請求封裝為一個對象，將請求的發起者和執行者解耦，支持對請求排隊以及撤銷和重做。它的類圖如下:

　　由于將請求都封裝成一個個命令對象了，使得我們可以集中處理或者延遲處理這些命令請求，而且不同的客戶對象可以共享這些命令，還可以控制請求的優先級、排隊、支持請求命令撤銷和重做等等。命令模式的這些好處是顯而易見的，但是，在實際使用過程中它的問題也暴露出來了。隨著請求的增多，請求的封裝類--命令類也會越來越多，尤其是GUI應用中，請求是非常多的。越來越多的命令類會導致類爆炸，難以管理。關于類爆炸這個問題，GOF很早就意識到了，他們提出了一個解決方法：對于簡單的不能取消和不需要參數的命令，可以用一個命令類模板來參數化該命令的接收者，用接收者類型來參數化命令類，并維護一個接收者對象和一個動作之間的綁定，而這一動作是用指向同一個成員函數的指針存儲的。具體代碼是這樣的：
簡單命令類的定義：

構造器存儲接收者和對應實例變量中行為。Execute操作實施接收者的這個動作。

為創建一個調用MyClass類的一個實例上的Action行為的Command對象，僅需要如下代碼：

　　通過一個泛型的簡單命令類來避免不斷創建新的命令類，是一個不錯的辦法，但是，這個辦法不完美，即它只能是簡單的命令類，不能對復雜的，甚至所有的命令類泛化，這是它的缺陷，所以，它只是部分的解決了問題。我想我可以改進這個辦法缺陷，完美的解決類爆炸的問題。在c++11之前我不知道有沒有人解決過這個問題，至少我沒看到過?，F在可以通過c++11來完美的解決這個問題了。

c++11改進命令模式

　　要完美的解決命令模式類爆炸問題的關鍵是如何定義個通用的泛化的命令類，這個命令類可以泛化所有的命令，而不是GOF提到的簡單命令。我們再回過頭來看看GOF中那個簡單的命令類的定義，它只是泛化了沒有參數和返回值的命令類，命令類內部引用了一個接收者和接收者的函數指針，如果接收者的行為函數指針有參數就不能通用了，所以我們要解決的關鍵問題是如何讓命令類能接受所有的成員函數指針或者函數對象。
　　有沒有一個能接受所有成員函數、普通函數和函數對象的類呢？有，在c++11中可以有，我上一篇博文中提到了一個萬能的函數包裝器，它可以接受所有的函數對象、fucntion和lamda表達式，它行不行呢？不行，因為它還不夠完美，它還不能接受成員函數呢，所以它還不是真正的萬能的函數包裝器。我打算在它的基礎上再擴展一下，讓它為一個真正的萬能的函數包裝器。

　　接受function、函數對象、lamda和普通函數的包裝器：

接受成員函數的包裝器：

　　通過重載的Wrap讓它能接收成員函數。這樣一個真正意義上的萬能的函數包裝器就完成了?，F在再來看，它是如何應用到命令模式中，完美的解決類爆炸的問題。

　　一個通用的泛化的命令類：

測試代碼：

我們在通用的命令類內部定義了一個萬能的函數包裝器，使得我們可以封裝所有的命令，增加新的請求都不需要重新定義命令了，完美的解決了命令類爆炸的問題。