首頁 > Java > java教程 > 主體

Java設計模式中關於命令模式的實例講解

黄舟
發布: 2017-08-10 09:58:22
原創
1583 人瀏覽過

指令模式就是對指令的封裝,下文給大家介紹了指令模式類別圖中的基本結構,對java設計模式之命令模式相關知識有興趣的朋友一起看看吧

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

類型:行為類別模式

類別圖:

#命令模式的結構

#        顧名思義,指令模式是對指令的封裝,先來看看指令模式類別圖中的基本結構:

  • Command類別:是一個抽象類別,類別中對需要執行的指令進行聲明,一般來說要對外公佈一個execute方法用來執行指令。

  • ConcreteCommand類別:Command類別的實作類,將抽象類別中宣告的方法實作。

  • Client類別:最終的客戶端呼叫類別。

        以上三個類別的作用應該是較好理解的,以下我們將重點放在Invoker類別和Recevier類別中。

  • Invoker類別:呼叫者,負責呼叫指令。

  • Receiver類別:接收者,負責接收指令並且執行指令。

        所謂對命令的封裝,說白了,無非就是把一系列的操作寫到一個方法中,然後供客戶端調用就行了,反映到類別圖上,只需要一個ConcreteCommand類別和Client類別就可以完成命令的封裝,即使再進一步,為了增加靈活性,可以再增加一個Command類別進行適當地抽象,這個呼叫者和接收者到底是什麼作用呢?

        其實大家可以換一個角度去想:假如僅僅是簡單地把一些操作封裝起來當作一條指令供別人調用,怎麼能稱為一種模式呢?命令模式作為一種行為類別模式,首先要做到低耦合,耦合度低了才能提高靈活性,而加入呼叫者和接收者兩個角色的目的也正是為此。指令模式的一般
程式碼如下:


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("接受者-业务逻辑处理"); 
 } 
} 
public class Client { 
 public static void main(String[] args){ 
  Receiver receiver = new Receiver(); 
  Command command = new ConcreteCommand(receiver); 
  //客户端直接执行具体命令方式(此方式与类图相符) 
  command.execute(); 
 
  //客户端通过调用者来执行命令 
  Invoker invoker = new Invoker(); 
  invoker.setCommand(command); 
  invoker.action(); 
 } 
}
登入後複製

        透過程式碼我們可以看到,當我們呼叫時,執行的時序首先是呼叫者類,然後是指令類,最後是接收者類別。也就是說一條指令的執行被分成了三步,它的耦合度要比把所有的操作都封裝到一個類別中要低的多,而這也正是指令模式的精髓所在:把指令的呼叫者與執行者分開,使雙方不必關心對方是如何運作的。

指令模式的優缺點

#        首先,指令模式的封裝性很好:每個指令都被封裝起來,對於客戶端來說,需要什麼功能就去呼叫對應的命令,而無需知道命令具體是怎麼執行的。例如有一組檔案操作的指令:新建檔案、複製檔案、刪除檔案。如果把這三個操作都封裝成一個命令類,客戶端只需要知道有這三個命令類即可,至於命令類中封裝好的邏輯,客戶端則無需知道。

        其次,命令模式的擴展性很好,在命令模式中,在接收者類別中一般會對操作進行最基本的封裝,命令類別則透過對這些基本的操作進行二次封裝,當增加新命令的時候,對命令類別的編寫一般不是從零開始的,有大量的接收者類別可供調用,也有大量的命令類別可供調用,程式碼的複用性很好。例如,在文件的操作中,我們需要增加一個剪切文件的命令,只需要把複製文件和刪除文件這兩個命令組合一下就行了,非常方便。

        最後請先說一下指令模式的缺點,那就是指令如果很多,發展起來就要頭痛了。特別是很多簡單的指令,實作起來就幾行程式碼的事,而使用指令模式的話,不用管指令多簡單,都需要寫一個指令類別來封裝。

命令模式的適用場景

       對大多數請求-回應模式的功能,較適合使用指令模式,如指令模式定義說的那樣,命令模式對實現記錄日誌、撤銷操作等功能比較方便。 

 總結

#

       對於一個場合到底用不用模式,這對所有的開發人員來說都是一個很糾結的問題。有時候,因為預見到需求上會發生的某些變化,為了系統的靈活性和可擴展性而使用了某種設計模式,但這個預見的需求偏偏沒有,相反,沒預見到的需求倒是來了不少,導致在修改程式碼的時候,使用的設計模式反而起了相反的作用,以至於整個專案組怨聲載道。這樣的例子,我相信每個程式設計者都遇過。所以,基於敏捷開發的原則,我們在設計程式的時候,如果按照目前的需求,不使用某種模式也能很好地解決,那麼我們就不要引入它,因為要引入一種設計模式並不困難,我們大可以在真正需要用到的時候再對系統進行一下,引入這個設計模式。

       拿指令模式來說吧,我們開發中,請求-回應模式的功能非常常見,一般來說,我們會把對請求的回應操作封裝到一個方法中,這個封裝的方法可以稱之為命令,但不是命令模式。到底要不要把這種設計上升到模式的高度就要另行考慮了,因為,如果使用命令模式,就要引入調用者、接收者兩個角色,原本放在一處的邏輯分散到了三個類中,設計時,必須考慮這樣的代價是否值得。

以上是Java設計模式中關於命令模式的實例講解的詳細內容。更多資訊請關注PHP中文網其他相關文章!

相關標籤:
來源:php.cn
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn
熱門教學
更多>
最新下載
更多>
網站特效
網站源碼
網站素材
前端模板