Command 模式是最讓我疑惑的一個模式我在閱讀了很多代碼後才感覺隱約掌握其大概原理我認為理解設計模式最主要是掌握起原理構造這樣才對自己實際編程有指導作用Command 模式實際上不是個很具體規定很多的模式正是這個靈活性讓人有些confuse
Command 定義
不少Command 模式的代碼都是針對圖形界面的它實際就是菜單命令我們在一個下拉菜單選擇一個命令時然後會執行一些動作
將這些命令封裝成在一個類中然後用戶(調用者)再對這個類進行操作這就是Command 模式換句話說本來用戶(調用者)是直接調用這些命令的如菜單上打開文檔(調用者)就直接指向打開文檔的代碼使用Command 模式就是在這兩者之間增加一個中間者將這種直接關系拗斷同時兩者之間都隔離基本沒有關系了
顯然這樣做的好處是符合封裝的特性降低耦合度Command 是將對行為進行封裝的典型模式Factory 是將創建進行封裝的模式從Command 模式我也發現設計模式一個通病:好象喜歡將簡單的問題復雜化 喜歡在不同類中增加第三者當然這樣做有利於代碼的健壯性 可維護性 還有復用性
如何使用?
具體的Command 模式代碼各式各樣因為如何封裝命令不同系統有不同的做法下面事例是將命令封裝在一個Collection 的List 中任何對象一旦加入List 中實際上裝入了一個封閉的黑盒中對象的特性消失了只有取出時才有可能模糊的分辨出:
典型的Command 模式需要有一個接口接口中有一個統一的方法這就是將命令/請求封裝為對象:
public interface Command {
public abstract void execute ( );
}
具體不同命令/請求代碼是實現接口Command下面有三個具體命令
public class Engineer implements Command {
public void execute( ) {
//do Engineers command
}
}
public class Programmer implements Command {
public void execute( ) {
//do programmers command
}
}
public class Politician implements Command {
public void execute( ) {
//do Politicians command
}
}
按照通常做法我們就可以直接調用這三個Command但是使用Command 模式我們要將他們封裝起來扔到黑盒子List 裡去:
public class producer{
public static List produceRequests() {
List queue = new ArrayList();
queueadd( new DomesticEngineer() );
queueadd( new Politician() );
queueadd( new Programmer() );
return queue;
}
}
這三個命令進入List 中後已經失去了其外表特征以後再取出也可能無法分辨出誰是Engineer 誰是Programmer 了看下面如何調用Command 模式:
public class TestCommand {
public static void main(String[] args) {
List queue = ProducerproduceRequests();
for (Iterator it = erator(); ithasNext(); )
//取出List 中東東其他特征都不能確定只能保證一
個特征是%正確
// 他們至少是接口Command 的兒子所以強制轉換
類型為接口Command
((Command)itnext())execute();
}
}
由此可見調用者基本只和接口打交道不合具體實現交互這也體現了一個原則面向接口編程這樣以後增加第四個具體命令時就不必修改調用者TestCommand 中的代碼了
理解了上面的代碼的核心原理在使用中就應該各人有自己方法了特別是在如何分離調用者和具體命令上有很多實現方法上面的代碼是使用從List 過一遍的做法這種做法只是為了演示
使用Command 模式的一個好理由還因為它能實現Undo 功能每個具體命令都可以記住它剛剛執行的動作並且在需要時恢復
Command 模式在界面設計中應用廣泛Java 的Swing 中菜單命令都是使用Command 模式由於Java 在界面設計的性能上還有欠缺因此界面設計具體代碼我們就不討論網絡上有很多這樣的示例
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27389.html
