設計模式之命令模式-有解無憂

本文通過解決老王經常搞錯借書人的問題，來引出行為型模式中的命令模式，為了在案例之上理解的更加透徹，我們需要了解命令模式在原始碼中的應用，最后指出命令模式的應用場景和優缺點，

讀者可以拉取完整代碼到本地進行學習，實作代碼均測驗通過后上傳到碼云，

一、引出問題

老王的書房藏書越來越多，每天來借書的人絡繹不絕，每天有人借書、還書、老王將A借的書算到B頭上的烏龍事件頻出，老王和小王就商量著手解決這個問題，

小王提議，在老王和借書者之間再增加一個“記錄員”角色，記錄員只管報名字就行了，具體是借什么書由借書者自己決定就好了，

老王說：這能解區域分問題，但在真實的場景下，不可能來一個借書者“記錄員”就跑一趟，而且借書者有時候會借一半臨時有事就不借了，這些問題你也要考慮進去，

老王接著說：你應該，在“記錄員”角色中，增加一個佇列，將所有借書者都放到一個佇列中，既有往佇列中放命令的方法，也有從命令中移除的方法，方便“記錄員”請求排隊和“撤銷”，

二、命令模式的概念和應用

老王提出來的正是命令模式的“白話文解釋”，我們來看命令模式的官方概念：將一個請求封裝為一個物件，使發出請求的責任和執行請求的責任分割開，解耦合，這樣兩者之間通過命令物件進行溝通，這樣方便將命令物件進行存盤、傳遞、呼叫、增加與管理，

在命令模式中有三個角色：

抽象命令類（Command）角色：定義命令的介面，宣告執行的方法，

實作者/接收者（Receiver）（老王）角色：接收者，真正執行命令的物件，任何類都可能成為一個接收者，只要它能夠實作命令要求實作的相應功能，

具體命令（Concrete Command）（記錄員）角色：具體的命令，實作命令介面；通常會持有接收者，并呼叫接收者的功能來完成命令要執行的操作，

我們基于概念和角色劃分，實作代碼：

抽象命令類：

/**
 * 抽象命令類
 * @author tcy
 * @Date 25-08-2022
 */
public interface AbstractCommand {

    //只需要定義一個統一的執行方法
    void execute();
}

具體命令角色（老王）：

/**
 * 具體命令
 * @author tcy
 * @Date 25-08-2022
 */
public class ConcreteCommand implements AbstractCommand {

    //持有接受者物件
    private String clent;

    public ConcreteCommand(String clent){
        this.clent = clent;
    }

    @Override
    public void execute() {
        System.out.println("具體執行者角色（老王）："+clent+"借書...");

    }
}

接收者（記錄員）：

/**
 * 接收者
 * @author tcy
 * @Date 25-08-2022
 */
public class ReceiverCommand {

    //可以持有很多的命令物件
    private ArrayList<AbstractCommand> commands;

    public ReceiverCommand() {
        commands = new ArrayList();
    }

    public void setCommand(AbstractCommand cmd){
        commands.add(cmd);
    }

    public void removeCommand(AbstractCommand cmd){
        commands.remove(cmd);
    }

    // 發出命令
    public void borrowBookMeaaage() {
        System.out.println("接受者角色(記錄員)：有人來借書啦...");
        //通知全部命令
        for (int i = 0; i < commands.size(); i++) {
            AbstractCommand cmd = commands.get(i);
            if (cmd != null) {
                cmd.execute();
            }
        }
    }
}

客戶端（借書者）：

/**
 * @author tcy
 * @Date 25-08-2022
 */
public class Client {

    public static void main(String[] args) {

        //創建接收者
        //將訂單和接收者封裝成命令物件
        ConcreteCommand cmd1 = new ConcreteCommand( "A");
        ConcreteCommand cmd2 = new ConcreteCommand( "B");

        //創建具體命令者
        ReceiverCommand invoker = new ReceiverCommand();
        invoker.setCommand(cmd1);
        invoker.setCommand(cmd2);

        //喊一聲有人要借書
        invoker.borrowBookMeaaage();


    }

}

基于命令模式實作的代碼就實作了，但是看懂代碼是一回事，自己能寫出來就是另外一回事了，讀者最好根據案例重新仿寫一遍，

三、原始碼中的應用

在原始碼中使用命令模式的典型案例就是Jdk多執行緒章節中的Runnable ，Runnable 相當于命令模式中的抽象命令角色，Runnable 中的 run() 方法就當于 execute() 方法，

我們知道，Java中一個類實作Runnable 介面，那么該類就認為是一個執行緒，就相當于命令模式中的具體命令角色，

當我們呼叫start()方法后，就可以與別的執行緒強占CPU的資源，在占用CPU的執行緒中就會執行run()方法，CPU的調度者就相當于具體命令角色也即記錄員，Runnable 就完美的實作了用戶自定義執行緒和CPU的解耦合，

命令模式在Runnable 中的應用應該很好理解，

四、總結

優點很明顯，解耦了命令請求與實作，很容易的可以增加新命令，支持命令佇列，

但是，這樣會不可避免的使具體命令類過多，增加了理解上的困難，

設計模式學到這種程度，我們就會發現設計模式不是一種單一的技術，而是各種技術的綜合體，

我們在學習設計模式的時候一定不要僅局限于一種模式，而是站在一定的高度去整體衡量哪種設計模式才是最優的，

有時候我們會發現，使用設計模式會讓我們的代碼變得更加的復雜，但以自己目前的開發經驗又不能確定是否采用設計模式是一個好的選擇，

歸根結低，還是我們對設計模式掌握的不夠熟練，這就需要我們繼續深入學習設計模式，當我的學完再回頭看這些問題，就很自然的迎刃而解了，

已經連續更新了數十篇設計模式博客，推薦你結合學習，

一、設計模式概述

二、設計模式之工廠方法和抽象工廠

三、設計模式之單例和原型

四、設計模式之建造者模式

五、設計模式之代理模式

六、設計模式之配接器模式

七、設計模式之橋接模式

八、設計模式之組合模式

九、設計模式之裝飾器模式

十、設計模式之外觀模式

十一、外觀模式之享元模式

十二、設計模式之責任鏈模式

轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/503166.html

標籤：其他

上一篇：初識設計模式 - 工廠模式

下一篇：初識設計模式 - 工廠模式