命令模式與策略模式之己見

 

      以前項目寫過關於TR069協議報文處理的代碼（主要是基於SOAP協議發送一些遠程命令並處理響應），在設計的時候，想的是應用策略模式對報文進行解析處理，

下圖是主要代碼結構（和策略模式很像）

代碼類似於：

         /**
         * 1、需要解析的XML
         */
        String xml = "<xml>...</xml>";
        /**
         * 2、獲取xml類型
         */
        MessageType type = SoapMessageFactory.getRpcType(xml);
        /**
         * 3、初始化soapMessage(最好先判斷下xml類型)
         */
        SoapMessage soap = SoapMessageFactory.initSoap(type);
        /**
         * 4、解析xml，可通過header和body變量獲取結果
         */
        soap.parse(xml);

      但回過頭來仔細看，這哪是什么策略模式呢，明明是更符合命令模式（message對應command,paser對應receiver），策略模式和命令模式這么相似嗎，這么容易混淆？於是我就進行分析比較。

基本定義：

策略模式：定義一系列算法，把它們一個個封裝起來，並且使它們可以相互替換。該模式使得算法可獨立於它們的客戶變化。
命令模式：將一個請求封裝成一個對象，從而讓你使用不同的請求把客戶端參數化，對請求排隊或者記錄請求日志，可以提供命令的撤銷和恢復功能。

     以SOAP報文解析為例，先從設計思路分析。

     1、最初想法：將所有報文都統一看做為SoapMessage，定義不同的算法進行封裝，對不同的報文進行不同的解析。認為是策略模式。

     2、進一步：其實Soap報文根據不同的type相當於不同請求（命令），定義並封裝不同的算法，是與相應的報文對應的。認為是命令模式。

     第一種思路與策略模式的定義對比后就可以發現明顯是不對的，因為策略模式會要求不同算法相互替換，而不同報文解析是不能替換的。

      策略模式側重同一個問題可用不同的可替換的算法去解決，而實際使用中，說的苛刻些，調用者只取其一，執行一次算法即可；比如對數組排序，用插入排序算法排好序后，你不會再用堆排序重新拍一遍，又比如你用支付寶支付后，不會再用微信支付一遍；而這些場景都可以應用策略模式。

策略模式網上的例子很多，我覺得這篇文章總結的特別好：http://www.cnblogs.com/justinw/archive/2007/02/06/641414.html

 

      ====================分割線===================================

      而對於命令模式更多的解釋是這樣：不同問題使用不同算法或者側重將請求的發送者和接收者解耦，這難道真的抓住命令模式的本質了嗎？

      首先看一下命令模式的UML圖：

      有5個角色：Invoker（調用者）和Receiver（接收者）、command接口和ConcreteCommand實現類以及Client。

首先注明：如果對於跨進程或者跨機器的這種遠程的方法調用，使用類似命令模式的這種構造方法相信沒有人有異議，下面對命令模式的分析側重單一進程。

      網上很多人都使用下面的例子進行解釋：

class Invoker {
    private Command command;
    public Invoker(Command command) {
        this.command = command;
    }
    public void action(){
        this.command.execute();
    }
}

abstract class Command {
    public abstract void execute();
}

class ConcreteCommand extends Command {
    private Receiver receiver;
    public ConcreteCommand(Receiver receiver){
        this.receiver = receiver;
    }
    public void execute() {
        this.receiver.doSomething();
    }
}

class Receiver {
    public void doSomething(){
        System.out.println("接受者-業務邏輯處理");
    }
}

public class Client {
    public static void main(String[] args){
        Receiver receiver = new Receiver();
        Command command = new        ConcreteCommand(receiver);
        Invoker invoker = new Invoker(command);
        invoker.action();
    }
}

      上面的代碼看似和命令模式的類圖很吻合，我覺得更像是為了模式而模式所拼湊出的一段代碼，沒有太多實際意義，甚至會誤導人。這段代碼最多體現了命令模式定義的前半部分：“將一個請求封裝成一個對象，從而讓你使用不同的請求把客戶端參數化”，而即使用來說明這一部分，代碼也有部分是多余的，那就是Receiver；main方法的執行過程更像一個蹺蹺板，Invoker翹一下Command，Command翹一下Receiver，而Receiver執不執行、什么時候執行，為什么由別的對象說了算呢？！或者直接去掉Receiver，留下Invoker，Command和ConcreteCommand，Invoker保持對Command的引用，而ConcreteCommand封裝自己的特性，命令怎么執行由ConcreteCommand的邏輯確定，而這也體現了面向接口編程原則，Command依舊可獨立於Invoker變化。根據上面的分析，我總結了命令模式的一種變形，稱之為“簡約型命令模式”。

一）簡約型命令模式

UML圖：

      這里去掉了Receiver，Invoker持有對Command的引用，每個Command都有唯一的方法Execute()。在Client中加入了命令隊列（Queue為虛線，表示可有可無），Client可以一次生成一個命令，馬上執行，或者一次生成若干命令放入隊列，依次執行。

      這種方式真是像極了“策略模式”，這可能就是我把命令模式和策略模式混淆的原因，而這種模式不能稱為策略模式，就是因為算法是不可相互替代的，稱之為“簡約型命令模式”。

可參考：http://www.jdon.com/designpatterns/command.htm

 

      既然有簡約型，就對應會有較復雜的類型，當然主要還是參考定義，注重實現其后半部分：“對請求排隊或者記錄請求日志，可以提供命令的撤銷和恢復功能。”，我稱之為“異步事務性命令模式”。

二）異步事務型命令模式

當然還是先看UML圖：

      結構與原始的命令模式基本一樣，唯一修改的是Receiver對象，增加了一個pool屬性，用來接收Command，Invoker每次調用命令，並不會直接執行而是先寫入pool中，待Receiver等到合適時機去選擇執行，這種結構把Invoker和Receiver徹底解耦，Receiver完全不受Invoker制約，也完全體現了一個Receiver的角色。入隊的同時，還可以將命令持久化，以一種Write ahead log的形式對其進行記錄，還有ConcreteCommand中有個state屬性，很多介紹命令模式的文章對沒有對其進行說明，我認為這是實現事務必不可少的（可以用來指示此命令與某些命令是一組的，要么都執行成功，要么異常回滾，或者可以結合Composite模式使用），Receiver中添加的undo()和redo()方法就是和事務相關的操作，如果服務異常退出，重啟后，使用redo()方法結合wal日志進行恢復，如果事務執行中斷就需要根據命令執行前的狀態進行恢復。

      目前還沒有看到相關的實例。

最后還說一句：“不同問題使用不同算法或者側重將請求的發送者和接收者解耦”只是命令模式的一種表現形式，解耦、不同問題不同算法，太容易讓人和其他的模式相混淆，還是應該回到最初的定義去理解。

PS:最后寫的有點倉促，對於這種事務設計還要繼續研究