junit設計模式分析一命令模式

命令模式：

將乙個請求封裝成乙個物件，從而使你可用不同的請求對客戶進行引數化；對請求進行排隊或記錄請求日誌...

command模式告訴我們可以為乙個操作(方法)生成乙個物件並給出它的乙個"execute（執行）"方法。

注意：這裡都是乙個。

命令模式的構成：

1、客戶角色：建立乙個具體命令物件，並確定其接收者

2、命令角色：宣告乙個給所有具體命令類的抽象介面。這是乙個抽象角色，通常由乙個介面或抽象類實現

3、具體角色：　定義乙個接收者和行為之間的弱耦合，實現execute方法，負責呼叫接收者的相應操作

4、請求者角色：負責呼叫命令物件執行請求

5、接收者角色：負責具體實施和執行乙個請求

通過乙個模擬來方便我們的記憶：

當我們去飯店吃飯，點菜的時候，點菜就是乙個命令，命令並不會自己去完成，而是有乙個具體的接收者去完成的，點菜以後具體的實施是由廚師去完成的，那麼廚師就是乙個接收者，所以命令中要持有乙個廚師的引用，而廚師並不依賴任何其他的物件。

**實現：

命令的介面：

public inte***ce command

命令的實現：

public class concretecommand implements command 
public void docommand() 
}

接收者(廚師)：

public class receiver 
}

請求者(客戶端)：

public class client 
}

對應於junit3.8中的**實現

在junit3.8中定義了test介面

public inte***ce test

這裡的test介面就是command的介面，run方法就是command中的doaction方法

testcase是test介面的抽象實現。它增加了乙個測試名稱屬性，因為每乙個testcase在建立時都要有乙個名稱，如果乙個測試失敗了，便可識別出是哪個測試失敗。

public abstract class testcase extends assert implements test 
}

這樣測試人員，編寫測試用例時，只需繼承testcase，來完成run方法即可，然後junit獲得測試用例的請求，執行它的run方法，把測試結果記錄在testresult之中，目前可以暫且這樣理解。

效果：下面來考慮經過使用command模式後給系統的架構帶來了那些效果：

1、command模式將實現請求的一方（testcase開發）和呼叫一方（junit ）進行解藕

2、command模式使新的testcase很容易加入，無需改變已有的類，只需繼承testcase類即可，這樣方便了測試人員

3、command模式可以將多個testcase進行組合成乙個復合命令，你將看到testsuit就是它的復合命令，當然它使用了composite模式

4、command模式容易把請求的testcase組合成請求佇列，這樣使接收請求的一方（junit fromwork）,容易決定是否執行請求，一旦發現測試用例失敗或者錯誤可以立刻停止進行報告

5、command模式可以在需要的情況下，方便實現對請求的undo和redo，以及記錄log,這部分目前在junit中還沒有實現，將來是很容易加入的。

缺點：

由於命令模式只能為乙個操作(方法)生成乙個物件並給出它的乙個"execute（執行）"方法。

所以：10個操作就要生成10個物件，會造成類的膨脹的！！！而且沒個類中只能有乙個方法，然後由接收者去執行這個方法。

所以在junit3.8框架中就引入了介面卡模式，將在後文中詳細闡述！

一什麼叫做命令模式定義將請求封裝成物件，這可以讓你使用不同的佇列，請求，或者日誌請求來引數化其他物件。命令模式也支援撤銷操作。二使用場景當需要將發出請求的物件和執行請求的物件解耦的時候使用命令模式。三命令模式的構成命令模式包括 1 命令介面或者命令抽象類 command 定義命令類所需...

命令模式將乙個請求封裝為物件，從而使我們可用不同的請求對客戶進行引數化對請求排隊或者記錄請求日誌，以及支援可撤銷的操作。也稱為動作 action 模式事務 transaction 模式。結構圖示例 receiver接收者真正的命令執行者 public class receiver pub...

junit的底層主要是由觀察者模式，組合模式，模板模式，命令模式來實現的。在junit裡首先會初始化乙個主題物件testresult物件，這個物件裡面有增加的方法，所有的方法都實現了 testlistener介面，這個介面會把一系統測試過程的資訊傳遞給所有的然後會按照它們的方式顯示給用 ...

junit設計模式分析一 命令模式