命令模式的定義 定義: 將一個請求封裝成一個對象, 從而讓你使用不同的請求將客戶端參數化, 對請求排隊或者記錄請求日誌, 可以提供命令的撤銷和恢復功能 通俗的說, 就是當有不同的請求時, 將每一種請求都封裝成一個對象, 不同的請求調用不同的執行者來執行 命令模式的通用類圖如下: 其中各部分如下: 接 ...
命令模式的定義
定義: 將一個請求封裝成一個對象, 從而讓你使用不同的請求將客戶端參數化, 對請求排隊或者記錄請求日誌, 可以提供命令的撤銷和恢復功能
通俗的說, 就是當有不同的請求時, 將每一種請求都封裝成一個對象, 不同的請求調用不同的執行者來執行
命令模式的通用類圖如下:
其中各部分如下:
- Receiver 接收者. 就是幹活的角色, 命令傳遞到這裡是應該被執行的, 每一個Receiver對應了一個任務
- Command 命令角色. 需要執行的所有命令在這裡聲明, 命令角色通過調用Receiver進行命令的執行
- Invoker 調用者. 接收到命令, 並執行命令.
接收者代碼:
為什麼 Receiver 是一個抽象類呢? 因為接收者可以有多個, 有多個就需要定義一個所有特性的抽象集合.
命令角色是命令模式的核心, 其抽象的命令類代碼如下:
根據環境的需求,具體的命令類也可以有多個, 代碼如下:
在每個命令類中, 通過構造函數定義了該命令是針對哪一個接收者發出的, 定義一個命令接收的主題.
調用者非常簡單, 僅實現命令的傳遞, 代碼如下;
那麼,如何調用呢? 場景類代碼如下:
至此, 一個簡單的命令模式完成
命令模式的應用
命令模式的優點
- 類間解耦. 調用者與接收者之間沒有任何依賴關係, 調用者實現功能時只需要調用 Command 抽象類的 execute 方法即可, 不需要瞭解到底是哪個接收者執行.
- 可擴展性. Command 的子類可以非常容易的擴展, 而調用者Invoker和高層次的模塊 Client 不產生嚴重的代碼耦合
- 命令模式結合其他模式會更優秀. 命令模式可以結合責任鏈模式, 實現命令族解析任務; 結合模板方法模式, 則可以減少Command子類的膨脹問題
命令模式的缺點
Command的子類, 如果有N個命令, 問題就出來了, Command 的子類就是N個了, 這個類膨脹的非常大
命令模式的使用場景
只要認為是命令的地方就可以採用命令模式, 例如: 在GUI開發中, 一個按鈕的點擊是一個命令,可以採用命令模式; 模擬DOS命令的時候, 當然也要採用命令模式
在上面的代碼中, Receiver 暴露給了 Client, 這樣其實並不好, 命令模式的Receiver在實際應用中一般都會被封裝掉,每一個命令是對一個或多個Receiver的封裝, 我們可以在項目中通過有意義的類名或命令名處理命令角色和接收者角色的耦合關係,減少高層模塊對低層模塊的依賴關係, 提高系統的整體穩定性
修改後的代碼如下:
實現了對 接收者的封裝, 每個命令完成單一的職責, 而不是根據接收者的不同完成不同的職責, 在高層模塊的調用時就不用考慮接收者是誰的問題. 場景類代碼如下:
高層模塊直接下達命令即可, 完美!!
