設計模式之Command

原创 2004年06月24日 20:07:00

Command模式是最讓我疑惑的一個模式,我在閱讀了很多代碼後,才感覺隱約掌握其大概原理,我認爲理解設計模式最主要是掌握起原理構造,這樣才對自己實際編程有指導作用。Command模式實際上不是個很具體,規定很多的模式,正是這個靈活性,讓人有些confuse

Command定義
不少Command模式的代碼都是針對圖形介面的,它實際就是功能表命令,我們在一個下拉功能表選擇一個命令時,然後會執行一些動作。

將這些命令封裝成在一個類別中,然後用戶(呼叫者)再對這個類別進行操作,這就是Command模式,換句話說,本來用戶(呼叫者)是直接呼叫這些命令的,如功能表上打開文檔(呼叫者),就直接指向打開文檔的代碼,使用Command模式,就是在這兩者之間增加一個中間者,將這種直接關係拗斷,同時兩者之間都隔離,基本沒有關係了。

顯然這樣做的好處是符合封裝的特性,降低耦合度,Command是將對行爲進行封裝的典型模式,Factory是將創建進行封裝的模式,
Command模式,我也發現設計模式一個"通病":好象喜歡將簡單的問題複雜化, 喜歡在不同類別中增加第三者,當然這樣做有利於代碼的健壯性 可維護性 還有複用性。

如何使用?
具體的Command模式代碼各式各樣,因爲如何封裝命令,不同系統,有不同的做法。下面事例是將命令封裝在一個CollectionList,任何物件一旦加入List,實際上裝入了一個封閉的黑盒中,物件的特性消失了,只有取出時,才有可能模糊的分辨出:

典型的Command模式需要有一個介面。介面中有一個統一的方法,這就是"將命令/請求封裝爲物件":

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


具體不同命令/請求代碼是實現介面Command,下面有三個具體命令

public class Engineer implements Command {

  
public void execute( ) {
    
//do Engineer's command
  
}
}

public class Programmer implements Command {

  
public void execute( ) {
    
//do programmer's command
  
}
}

public class Politician implements Command {

  
public void execute( ) {
    
//do Politician's command
  
}
}

 

按照通常做法,我們就可以直接呼叫這三個Command,但是使用Command模式,我們要將他們封裝起來,扔到黑盒子List裏去:

public class producer{
  
public static List produceRequests() {
    
List queue = new ArrayList();
    
queue.add( new DomesticEngineer() );
    
queue.add( new Politician() );
    
queue.add( new Programmer() );
    
return queue;
  }

}

這三個命令進入List中後,已經失去了其外表特徵,以後再取出,也可能無法分辨出誰是Engineer 誰是Programmer,看下面如何呼叫Command模式:

public class TestCommand {
  
public static void main(String[] args) {
    

    List queue = Producer.produceRequests();
    
for (Iterator it = queue.iterator(); it.hasNext(); )
        //取出List中東東,其他特徵都不能確定,只能保證一個特徵是100%正確
,
        // 他們至少是介面Command"兒子"。所以強制轉換類別型爲介面
Command

        
((Command)it.next()).execute();
  

  }
}

由此可見,呼叫者基本只和介面打交道,不合具體實現交互,這也體現了一個原則,面向介面編程,這樣,以後增加第四個具體命令時,就不必修改呼叫者TestCommand中的代碼了。

理解了上面的代碼的核心原理,在使用中,就應該各人有自己方法了,特別是在如何分離呼叫者和具體命令上,有很多實現方法,上面的代碼是使用"List過一遍"的做法。這種做法只是爲了演示。

使用Command模式的一個好理由還因爲它能實現Undo功能。每個具體命令都可以記住它剛剛執行的動作,並且在需要時恢復。

Command模式在介面設計中應用廣泛。JavaSwing中功能表命令都是使用Command模式,由於Java在介面設計的性能上還有欠缺,因此介面設計具體代碼我們就不討論,網路上有很多這樣的示例。

設計模式之Command

Command模式是最讓我疑惑的一個模式,我在閱讀了很多代碼後,才感覺隱約掌握其大概原理,我認爲理解設計模式最主要是掌握起原理構造,這樣才對自己實際編程有指導作用。Command模式實際上不是個很具體...
  • alex197963
  • alex197963
  • 2007年05月12日 09:20
  • 555

大话西游之设计模式_起手篇

介绍了设计模式是什么。能干什么、及怎么运用? 通过西游记中故事的分析,将常用设计模式融合在故事的实现中,帮助大家理解&记住各种设计模式的概念及使用方法。 达到活学活用的情况~...
  • myhc2014
  • myhc2014
  • 2015年10月15日 10:52
  • 752

设计模式 —— 命令模式(Command Pattern)

命令模式(Command Pattern)概念: 概述:在软件设计中,我们经常会遇到某些对象发送请求,然后某些对象接受请求后执行,但发送请求的对象可能并不知道接受请求的对象是谁,执行的是什么动作。...
  • wwh578867817
  • wwh578867817
  • 2016年05月29日 18:34
  • 1251

設計模式之Builder

Builder模式定義:將一個複雜物件的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示。Builder模式是一步一步創建一個複雜的物件,它允許用戶可以只通過指定複雜物件的類型和內容就可以構建...
  • alex197963
  • alex197963
  • 2007年05月12日 09:28
  • 578

設計模式之Observer

Java深入到一定程度,就不可避免的碰到設計模式(design pattern)這一概念,瞭解設計模式,將使自己對java中的介面或抽象類別應用有更深的理解。設計模式在java的中型系統中應用廣泛,遵...
  • arielxp
  • arielxp
  • 2004年06月24日 20:06
  • 2313

設計模式之Template

Template定義:定義一個操作中演算法的骨架,將一些步驟的執行延遲到其子類別中。 其實Java的抽象類別本來就是Template模式,因此使用很普遍。而且很容易理解和使用,我們直接以示例開始: ...
  • arielxp
  • arielxp
  • 2004年06月24日 19:57
  • 1798

設計模式之Visitor

Visitor定義作用於某個物件群中各個物件的操作。 它可以使你在不改變這些物件本身的情況下,定義作用於這些物件的新操作。在Java中,Visitor模式實際上是分離了collection結構中的元素...
  • alex197963
  • alex197963
  • 2007年05月12日 09:15
  • 617

設計模式之Template

Template定義:定義一個操作中演算法的骨架,將一些步驟的執行延遲到其子類別中。其實Java的抽象類別本來就是Template模式,因此使用很普遍。而且很容易理解和使用,我們直接以示例開始: ...
  • alex197963
  • alex197963
  • 2007年05月12日 09:23
  • 669

設計模式之State

State的定義: 不同的狀態,不同的行爲;或者說,每個狀態有著相應的行爲。何時使用?State模式在實際使用中比較多,適合"狀態的切換"。因爲我們經常會使用If elseif else 進行狀態切換...
  • alex197963
  • alex197963
  • 2007年05月12日 09:18
  • 560

設計模式之Observer

Java深入到一定程度,就不可避免的碰到設計模式(design pattern)這一概念,瞭解設計模式,將使自己對java中的介面或抽象類別應用有更深的理解。設計模式在java的中型系統中應用廣泛,遵...
  • alex197963
  • alex197963
  • 2007年05月12日 09:21
  • 601
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:設計模式之Command
举报原因:
原因补充:

(最多只允许输入30个字)