15.4 命令模式的擴展 15.4.1 未講完的故事 上面的例子我們還沒有說完。想想看，客戶要求增加一項需求，那是不是頁面也增加，同時功能也要增加呢？如果不使用命令模式，客戶就需要先找需求組，然后找美工組，再找代碼組……你想讓客戶跳樓啊！使用命令模式后，客戶只管發命令模式，例如，需要增加一項需求，沒問題，我內部調動三個組通力合作，然后把結果反饋給你，這也正是客戶需要的。那這個要怎么修改呢？想想看，很簡單的！在AddRequirementCommand類的execute方法中增加對PageGroup和CodePage的調用就可以了，修改后的代碼如代碼清單15-19所示。 代碼清單15-19 修改后的增加需求 public?class?AddRequirementCommand?extends?Command?{ ?????//執行增加一項需求的命令 ?????public?void?execute()?{ ?????????????//找到需求組 ?????????????super.rg.find(); ?????????????//增加一份需求 ?????????????super.rg.add(); ?????????????//頁面也要增加 ?????????????super.pg.add(); ?????????????//功能也要增加 ?????????????super.cg.add(); ?????????????//給出計劃 ?????????????super.rg.plan(); ?????} } 看看，是不是解決問題了？客戶Client只需要發布命令，至于如何執行這個命令，是協調一個對象，還是兩個對象，都不需要關心，命令模式做了一層非常好的封裝。 15.4.2 反悔問題 我們的例子說到這里是不是應該真的結束了？不，還有一個問題會經常發生的：客戶發出命令，要撤回，怎么辦？就類似你使用Ctl+Z組合鍵（undo功能），發出一個命令，在沒有執行（這時只要重新setCommand就可以了）或執行后撤回（執行后撤回是狀態變更）該怎么實現呢？ 有兩種方法可以解決：一是結合備忘錄模式還原最后狀態，該方法適合接收者為狀態的變更情況，而不適合事件處理；二是通過增加一個新的命令，實現事件的回滾。例子中的“刪除一個頁面”就需要一個反命令：撤銷剛剛刪除頁面的命令，那客戶發出這樣一個命令，我們該怎么處理呢？ 我們這樣思考，反命令也是一個命令，那就是Command的一個子類，它實現的功能就是恢復剛剛刪除的頁面，然后我們再思考，誰能恢復刪除的頁面呢？當然是頁面組了，于是作為接收者的頁面組必須還有一個方法恢復最后刪除的頁面，也就是日志的回滾機制了，指定一個頁面，回滾回去。分析完畢，我們來看實現，注意：以下為示意代碼，請讀者自行在應用中進行實現。修正后的Group如代碼清單15-20所示。 代碼清單15-20 修改后的Group類 public?abstract?class?Group?{ ?????//甲乙雙方分開辦公，你要和那個組討論，你首先要找到這個組 ?????public?abstract?void?find(); ?????//被要求增加功能 ?????public?abstract?void?add(); ?????//被要求刪除功能 ?????public?abstract?void?delete(); ?????//被要求修改功能 ?????public?abstract?void?change(); ?????//被要求給出所有的變更計劃 ?????public?abstract?void?plan(); ?????//每個接收者都要對直接執行的任務可以回滾 ?????public?void?rollBack(){ ?????????????//根據日志進行回滾 ?????} } 僅僅增加了一個rollBack的方法，每個接收者都可以對自己實現的任務進行回滾。怎么回滾？根據事務日志進行回滾！新增加的一個命令CancelDeletePageCommand實現撤銷剛剛發出的刪除命令，如代碼清單15-21所示。 代碼清單15-21 撤銷命令 public?class?CancelDeletePageCommand?extends?Command?{ ?????//撤銷刪除一個頁面的命令 ?????public?void?execute()?{ ?????????????super.pg.rollBack(); ?????} } 然后就是用Invoker進行調用了，客戶選擇了執行這個撤銷動作，就可以進行撤銷操作，該示意代碼確實比較簡單，真正實現起來那是異常復雜的，為什么呢？事務日志處理是非常繁瑣的處理機制，想想數據庫的日志處理吧，你就能想象出這個日志有多復雜！