前言
設計模式也已經總結了十多種，總的來說的還是對java的三大特性進行反覆使用，形成的固定寫法，越往後面學習，越覺得23種設計模式就是對java三大特性總結的縮小版。僅個人愚見

定義：命令列模式並非一行行命令的執行，而是寫法上類似對一個具體邏輯的封裝。（內部進行封裝具體的實現）

Uml類圖

衍生出來命令列模式寫法

原始碼分析

由於實在是簡單，看著類圖就可以聯想出來具體的實現方式，這裡不進行貼程式碼，只是把命令列模式貼出來（還是貼…….）

Client( 客戶端)

package patterncommond;

public class Client {

    public
 
 static void main(String[] args) {

        Commond commond = new DeleCodeCommond();

        Invorker invorker = new Invorker();

        invorker.setCommond(commond);

        invorker.actionCommond();

        /* 撤銷不做了 */

        Commond undoCommond = new UnDoCodeCommond();
        invorker.setCommond(undoCommond);
        invorker.actionCommond();

    }
}
 

客戶端，類似使用程式的客戶，想要改需求，則需要通過Invorker（專案經理）釋出ActionCommond進行具體實現

Commond（命令）

package patterncommond;

public abstract class Commond {

    protected Coder coder = new Coder(); // 程式碼編寫
    protected MG mg = new MG();// ui切圖

    /**
     * 具體命令的執行模板
     */
    abstract void exe();
}

Inverker（專案經理）

package patterncommond;

public class Invorker {

    protected Commond commond; // 抽象命令

    /**
     * 設定命令
     * 
     * @param commond
     */
    public void setCommond(Commond commond) {
        this.commond = commond;
    }

    /**
     * 執行命令
     */
    public void actionCommond() {
        commond.exe();
    }
}

Inverker類只負責接受命令和分發（actionCommond）命令到下層進行具體實現

DelCodeCommond具體命令

package patterncommond;

public class DeleCodeCommond extends Commond {

    @Override
    void exe() {
        super.coder.find();
        super.coder.del();
        super.coder.plan();
    }

}

具體的一條命令，del 一行程式碼，Abstract Commond類中儲存了具體人員的引用，包括 MG，CODER …，刪除程式碼是Coder做的，那麼在具體的命令封裝類中呼叫相應的人員進行操作即可

Coder（程式碼工，哈哈）

package patterncommond;

public class Coder extends Group {

    @Override
    void add() {

        System.out.println("增加功能");
    }

    @Override
    void find() {
        System.out.println("找到 coder");
    }

    @Override
    void del() {

        System.out.println("del功能");
    }

    @Override
    void modify() {

        System.out.println("modify功能");
    }

    @Override
    void plan() {
        System.out.println("變更報告清單");
    }

}

Coder就是現實中的程式設計人員，進行具體的操作

MG(美工)

 package patterncommond;

public class MG extends Group {

    @Override
    void add() {

        System.out.println("MG add功能 ");

    }

    @Override
    void find() {
        System.out.println("找到 MG 組 ");

    }

    @Override
    void del() {
        System.out.println("MG del功能");

    }

    @Override
    void modify() {
        System.out.println("MG modify功能");

    }

    @Override
    void plan() {
        System.out.println("變更報告清單");
    }

}

MG就是現實中的編美工，ui設計，進行具體的操作

unDoCodeCommond

package patterncommond;

public class UnDoCodeCommond extends Commond {

    @Override
    void exe() {
        System.out.println("撤銷不做");
    }

}

撤銷不做了，當然這裡只是簡單的比較，同樣客戶也可以下一個需要MG和 Coder配合命令，當然現實中就是協同工作

Eg：更新ui的同時coder也需要更新

@overide
Public void exe(){

        super.coder.find();
        super.coder.del();
        super.coder.plan();
        super.mg.find();
        super.mg.modify();
        super.mg.plan();
}

執行結果

找到 coder
del功能
變更報告清單
找到 MG
Modify 功能
變更報告清單

命令列通用類圖

總結：在這個類圖中，我們看到三個角色：
Receiver 角色：這個就是幹活的角色，命令傳遞到這裡是應該被執行的，具體到上面我們的例子中就是
Group 的三個實現類；
Command 角色：就是命令，需要我執行的所有命令都這裡宣告；
Invoker 角色：呼叫者，接收到命令，並執行命令，例子中我這裡專案經理就是這個角色；

命令模式比較簡單，但是在專案中使用是非常頻繁的，封裝性非常好，因為它把請求方（ Invoker）和執
行方（ Receiver）分開了，擴充套件性也有很好的保障。但是，命令模式也是有缺點的，你看 Command 的子類沒

引用：23種設計模式 作者 cbf4Life