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 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模式:
[code]public class TestCommand {
public static void main(String[] args) {
List queue = Producer
produceRequests();
for (Iterator it = erator(); it
hasNext(); )
//取出List中東東
其他特征都不能確定
只能保證一個特征是
%正確
// 他們至少是接口Command的
兒子
所以強制轉換類型為接口Command
((Command)it
next())
execute();
}
} [/code]
由此可見
調用者基本只和接口打交道
不合具體實現交互
這也體現了一個原則
面向接口編程
這樣
以後增加第四個具體命令時
就不必修改調用者TestCommand中的代碼了
理解了上面的代碼的核心原理
在使用中
就應該各人有自己方法了
特別是在如何分離調用者和具體命令上
有很多實現方法
上面的代碼是使用
從List過一遍
的做法
這種做法只是為了演示
使用Command模式的一個好理由還因為它能實現Undo功能
每個具體命令都可以記住它剛剛執行的動作
並且在需要時恢復
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27499.html