鍍金池/ 教程/ Java/ 命令模式
訪(fǎng)問(wèn)者模式
訪(fǎng)問(wèn)者模式討論篇:java的動(dòng)態(tài)綁定與雙分派
責任連模式
迭代器模式
策略模式
命令模式
單例模式
建造者模式
解釋器模式
工廠(chǎng)方法模式
備忘錄模式
原型模式
單例模式討論篇:?jiǎn)卫J脚c垃圾回收
觀(guān)察者模式
模版方法模式
創(chuàng )建類(lèi)模式總結篇
抽象工廠(chǎng)模式
中介者模式

命令模式

定義:將一個(gè)請求封裝成一個(gè)對象,從而讓你使用不同的請求把客戶(hù)端參數化,對請求排隊或者記錄請求日志,可以提供命令的撤銷(xiāo)和恢復功能。

類(lèi)型:行為類(lèi)模式

類(lèi)圖:

http://wiki.jikexueyuan.com/project/java-design-pattern/images/command-pattern-1.jpg" alt="command-pattern" />

命令模式的結構

顧名思義,命令模式就是對命令的封裝,首先來(lái)看一下命令模式類(lèi)圖中的基本結構:

  • Command類(lèi):是一個(gè)抽象類(lèi),類(lèi)中對需要執行的命令進(jìn)行聲明,一般來(lái)說(shuō)要對外公布一個(gè)execute方法用來(lái)執行命令。
  • ConcreteCommand類(lèi):Command類(lèi)的實(shí)現類(lèi),對抽象類(lèi)中聲明的方法進(jìn)行實(shí)現。
  • Client類(lèi):最終的客戶(hù)端調用類(lèi)。

以上三個(gè)類(lèi)的作用應該是比較好理解的,下面我們重點(diǎn)說(shuō)一下Invoker類(lèi)和Recevier類(lèi)。

  • Invoker類(lèi):調用者,負責調用命令。
  • Receiver類(lèi):接收者,負責接收命令并且執行命令。

所謂對命令的封裝,說(shuō)白了,無(wú)非就是把一系列的操作寫(xiě)到一個(gè)方法中,然后供客戶(hù)端調用就行了,反映到類(lèi)圖上,只需要一個(gè)ConcreteCommand類(lèi)和Client類(lèi)就可以完成對命令的封裝,即使再進(jìn)一步,為了增加靈活性,可以再增加一個(gè)Command類(lèi)進(jìn)行適當地抽象,這個(gè)調用者和接收者到底是什么作用呢?

其實(shí)大家可以換一個(gè)角度去想:假如僅僅是簡(jiǎn)單地把一些操作封裝起來(lái)作為一條命令供別人調用,怎么能稱(chēng)為一種模式呢?命令模式作為一種行為類(lèi)模式,首先要做到低耦合,耦合度低了才能提高靈活性,而加入調用者和接收者兩個(gè)角色的目的也正是為此。命令模式的通用代碼如下:

    class Invoker {
        private Command command;
        public void setCommand(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("接受者-業(yè)務(wù)邏輯處理");
        }
    }

    public class Client {
        public static void main(String[] args){
            Receiver receiver = new Receiver();
            Command command = new ConcreteCommand(receiver);
            //客戶(hù)端直接執行具體命令方式(此方式與類(lèi)圖相符)
            command.execute();

            //客戶(hù)端通過(guò)調用者來(lái)執行命令
            Invoker invoker = new Invoker();
            invoker.setCommand(command);
            invoker.action();
        }
    }

通過(guò)代碼我們可以看到,當我們調用時(shí),執行的時(shí)序首先是調用者類(lèi),然后是命令類(lèi),最后是接收者類(lèi)。也就是說(shuō)一條命令的執行被分成了三步,它的耦合度要比把所有的操作都封裝到一個(gè)類(lèi)中要低的多,而這也正是命令模式的精髓所在:把命令的調用者與執行者分開(kāi),使雙方不必關(guān)心對方是如何操作的。

命令模式的優(yōu)缺點(diǎn)

首先,命令模式的封裝性很好:每個(gè)命令都被封裝起來(lái),對于客戶(hù)端來(lái)說(shuō),需要什么功能就去調用相應的命令,而無(wú)需知道命令具體是怎么執行的。比如有一組文件操作的命令:新建文件、復制文件、刪除文件。如果把這三個(gè)操作都封裝成一個(gè)命令類(lèi),客戶(hù)端只需要知道有這三個(gè)命令類(lèi)即可,至于命令類(lèi)中封裝好的邏輯,客戶(hù)端則無(wú)需知道。

其次,命令模式的擴展性很好,在命令模式中,在接收者類(lèi)中一般會(huì )對操作進(jìn)行最基本的封裝,命令類(lèi)則通過(guò)對這些基本的操作進(jìn)行二次封裝,當增加新命令的時(shí)候,對命令類(lèi)的編寫(xiě)一般不是從零開(kāi)始的,有大量的接收者類(lèi)可供調用,也有大量的命令類(lèi)可供調用,代碼的復用性很好。比如,文件的操作中,我們需要增加一個(gè)剪切文件的命令,則只需要把復制文件和刪除文件這兩個(gè)命令組合一下就行了,非常方便。

最后說(shuō)一下命令模式的缺點(diǎn),那就是命令如果很多,開(kāi)發(fā)起來(lái)就要頭疼了。特別是很多簡(jiǎn)單的命令,實(shí)現起來(lái)就幾行代碼的事,而使用命令模式的話(huà),不用管命令多簡(jiǎn)單,都需要寫(xiě)一個(gè)命令類(lèi)來(lái)封裝。

命令模式的適用場(chǎng)景

對于大多數請求-響應模式的功能,比較適合使用命令模式,正如命令模式定義說(shuō)的那樣,命令模式對實(shí)現記錄日志、撤銷(xiāo)操作等功能比較方便。

總結

對于一個(gè)場(chǎng)合到底用不用模式,這對所有的開(kāi)發(fā)人員來(lái)說(shuō)都是一個(gè)很糾結的問(wèn)題。有時(shí)候,因為預見(jiàn)到需求上會(huì )發(fā)生的某些變化,為了系統的靈活性和可擴展性而使用了某種設計模式,但這個(gè)預見(jiàn)的需求偏偏沒(méi)有,相反,沒(méi)預見(jiàn)到的需求倒是來(lái)了不少,導致在修改代碼的時(shí)候,使用的設計模式反而起了相反的作用,以至于整個(gè)項目組怨聲載道。這樣的例子,我相信每個(gè)程序設計者都遇到過(guò)。所以,基于敏捷開(kāi)發(fā)的原則,我們在設計程序的時(shí)候,如果按照目前的需求,不使用某種模式也能很好地解決,那么我們就不要引入它,因為要引入一種設計模式并不困難,我們大可以在真正需要用到的時(shí)候再對系統進(jìn)行一下,引入這個(gè)設計模式。

拿命令模式來(lái)說(shuō)吧,我們開(kāi)發(fā)中,請求-響應模式的功能非常常見(jiàn),一般來(lái)說(shuō),我們會(huì )把對請求的響應操作封裝到一個(gè)方法中,這個(gè)封裝的方法可以稱(chēng)之為命令,但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了,因為,如果使用命令模式,就要引入調用者、接收者兩個(gè)角色,原本放在一處的邏輯分散到了三個(gè)類(lèi)中,設計時(shí),必須考慮這樣的代價(jià)是否值得。

下一篇:解釋器模式