Command定義如下： 將來自客戶端的請求傳入一個物件，無需瞭解這個請求啟用的動作或有關接受這個請求的處理細節。

是不是有點迷糊。不知其說的是啥。哈哈。彆著急下面聽我慢慢到來。

本人覺得，命令模式就是把一些具體的命令封裝成一此具體的類，這此類實現同一個介面或者是抽象類。然後把這些類組織到起，然後統一來執行，完成一個具體的業務流程。

它的優點是：解藉了傳送者與接收者之間的聯絡。傳送者呼叫一個操作，接收者接受請求執行相應的動作，說白了就是呼叫一個具體的類來執行相應的方法。因為使用Command模式解耦，傳送者無需知道接受者任何介面。

比如說，對檔案進行操作，如開啟、關閉、列印。正常的操作就是使用者點選“開啟”按紐，就執行開啟命令，在按紐的單擊事件中寫個方法就可以了。但如要應用Command模式，就要把其抽象出介面，把這三個操作封裝成單獨的類。也許有人要問，為什麼要把簡單的問題複雜化呢？。雖然在程式碼量上有所增加，這樣做有利於程式碼的健壯性 可維護性 還有複用性。這是前人總結出來的經驗。

說了半天，如何使用呢，別說費話了，“必需的”。

具體的Command模式程式碼各式各樣,因為如何封裝命令,不同系統,有不同的做法。

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

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

具體不同命令/請求程式碼是實現介面Command,下面有三個具體命令（開啟命令、關閉命令、列印命令）

public class Open implements Command {

　　public void execute( ) {
          System.out.println("開啟");
　　}
} 
public class Close implements Command {

　　public void execute( ) {
          System.out.println("關閉");
　　}
}

public class Print implements Command {

　　public void execute( ) {
          System.out.println("列印");
　　}
}
 

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

public class producer{
　　public static List produceRequests() {
　　　　List queue = new ArrayList();
　　　　queue.add( new Open() );
　　　　queue.add( new Close() );
　　　　queue.add( new Print() );
　　　　return queue; 
　　}

}

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

public class TestCommand {
　　public static void main(String[] args) {
　　　　
　　　　List queue = Producer.produceRequests();
　　　　for (Iterator it = queue.iterator(); it.hasNext(); )
　　　　　　
　//客戶端直接呼叫execute方法，無需知道被呼叫者的其它更多類的方法名。
　　　　　　　　((Command)it.next()).execute();
　　

　　}
} 

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

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