先來看一下命令模式的類圖
乍一看好像類很多，其實我們逐個分析他們。
類圖中存在的類可以分為：invoker、icommand、conceretecommand、receiver
invoker類 上層直接調取invoker類
icommand 是對命令的抽象
conceretecommand 是命令的具體實現 我們有多少個命令就有多少個具體的實現但是這個實現也是虛實現，真正的實現方法還是調取的receiver類的方法
receiver 是我們真正的實現 其實它也可以向上抽取公共部分
public inte***ce icommand
public class command1impl implements icommand
@override
public void excute()
}public class command2impl implements icommand
@override
public void excute()
}
public class receive1
}public class receive2
}
public class invoke
public void dowork()
}
public static void main(string args)
result:
receive1 dosomething...
如果你發現client上層的呼叫者需要對receive類知曉，那麼你觀察的還是挺仔細的。如此一來我們就要將receive的構建在命令的具體實現中指定了，其實通過它的構造依然可以指定。
命令模式的優點很明顯，我們可以對不同的命令進行擴充套件而且類之間的耦合程度很低。
但是它的缺點也很明顯，我們不同的命令都需要乙個子類去實現。子類的膨脹是乙個問題，我們可以結合例如模板模式將公共的部分抽取至上層以減少子類的膨脹等。
那還有個問題？如果我們的命令類中的方法需要多個receive共同實現才能完成業務呢？其實此時我們就可以把所有的receive抽取在父類中就是我們的icommand中，由子類去定義具體實現就好了。
值得一提的是，我們的設計模式其實並不是完全一致的，在運用過程中或多或少都有變形，只有根據需要靈活運用它們才能發揮姮好的作用而不是一味的照搬照抄。這樣反而失去了設計模式的真正意義哦。
最後大家要記住，命令模式更關注的是呼叫者和接受者的解耦！這點很重要！
ok，以上！有不足之處歡迎指正！
設計模式之命令模式
command pattern 將請求封裝成物件，這可以讓你使用不同的請求，佇列，或者是日誌請求來引數化其他物件，命令模式也可以支援撤銷操作。命令模式有兩種實現方式 1.在命令管理器中提供設定當前命令接受者的方法，當執行訊息或者是有訊息壓入的時候直接將命令傳送給當前設定的接受者。2.在命令管理器中建...
設計模式之命令模式
當我們有一台多功能的印表機,然後通過電腦直接進行任務,如圖 如果通過這樣的設計直接去呼叫多功能一體機的功能,就會存在此時此刻只能進行乙個任務,不允許有多個客戶端同時操作.那麼現在我們就需要考慮一種新的設計模式,叫做命令設計模式。命令設計模式 將乙個請求封裝為乙個物件,從而使你可用不同的請求對客戶進行...
設計模式之命令模式
1 命令模式 commond 將乙個請求封裝為乙個物件，從而使你可用不同的請求對客戶進行引數化 對請求排隊或記錄請求日誌，以及支援可撤銷的操作。uml圖如下 2 命令模式作用的優點 第一，它能較容易地設計乙個命令佇列 第二，在需要的情況下，可以較容易地將命令記入日誌 第三，允許接收者請求的一方決定是...