JUnit的源碼相比于spring和hibernate來說比較簡單，但麻雀雖小，五臟俱全，其中用到了比較多的設(shè)計模式。很多人已經(jīng)在網(wǎng)上分享了他們對JUnit源碼解讀心得，我這篇小文談不出什么新意，本來不打算寫，可近工作上暫時無事可做，那寫寫吧，結(jié)合《設(shè)計模式》來看看。
    我讀的是JUnit3.0的源碼，目前JUnit已經(jīng)發(fā)布到4.0版本了，盡管有比較大的改進，但基本的骨架不變，讀3.0是為了抓住重點，省去對旁支末節(jié)的關(guān)注。我們來看看JUnit的核心代碼，也是Junit.framework包，除了4個輔助類（Assert，AssertFailedError，Protectable，TestFailure），剩下的是我們需要重點關(guān)注的了。我先展示一張UML類圖：

    我們先不去關(guān)注TestDecorator類（此處是Decorator模式，下篇文章再講），看看Test接口，以及它的兩個實現(xiàn)類TestCase和TestSuite。很明顯，此處用到了Command模式，為什么要使用這個模式呢？讓我們先來看看什么是Command模式。

Command模式

Command模式是行為型模式之一

1.意圖：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數(shù)化；對請求排隊或者記錄請求日志，以及支持可撤銷的操作。
2.適用場景：
1）抽象出待執(zhí)行的動作以參數(shù)化對象，Command模式是回調(diào)函數(shù)的面向?qū)ο蟀姹��；卣{(diào)函數(shù)，我想大家都明白，函數(shù)在某處注冊，然后在稍后的某個時候被調(diào)用。
2）可以在不同的時刻指定、排列和執(zhí)行請求。
3）支持修改日志，當(dāng)系統(tǒng)崩潰時，這些修改可以被重做一遍。
4）通過Command模式，你可以通過一個公共接口調(diào)用所有的事務(wù)，并且也易于添加新的事務(wù)。

3。UML圖：