這個時候我有兩個選擇，一是直接就寫代碼，一是先寫個測試。當然，我選擇的是先寫個測試，之所以擺明了這二個當然是為了比較了。先說如果我先寫代碼，那么我就直接進入了目標功能的角色，因為現在似乎目標很明確，我要給dataBuilder添加一個能處理監聽器的功能，在使用ResultSet解析器解析完成一個Document后觸發解析完成事件，通知所有注冊的監聽器，并將解析完成的結果通過事件對象傳遞給監聽器進行處理。在以前，我會立刻想到如何添加事件，如何處理事件列表，還有兩個必要的接口，一個是監聽器接口，一個是事件接口，一些簡要的構思之后，不用多少時間就可以完成這些工作，然后就開始調試。
上面那么說，主要是為了對比，現在我是先寫測試的。當然，如上所述目標現在似乎也很明確的，那么無論如何寫個測試類吧，在寫上必要的to do list之后，我開始想如果現在代碼寫完了，我要怎樣來使用它呢。哦，對了，測試這個之前還要寫個測試使用的監聽器實現，這個實現可以很簡單，把解析結果Document干掉好了，呵呵，驗證結果還更容易，那就把它所有節點remove掉好了，^_^。（注：這里的測試還沒有到主功能，只是先做測試監聽器部分）不過這個時候，我突然覺得目前這個設計似乎還是有些麻煩（懶惰是程序員的通病，sweat，每次想偷懶都想起這句），要寫監聽器，還要讓dataBuilder處理監聽列表觸發事件，雖然讓過濾數據操作可以很獨立地添加，而監聽器的注冊也可以通過XML配置文件來完成，但還是顯得多余，好像目前這個需求只要一個Decorator模式，寫一個修飾類來修飾ResultSet解析器就差不多了，以后需要新的功能，換Decorator就可以了，也可以相互嵌套來完成多個功能，這樣的話，就不需要對dataBuilder動太多手腳了。sweat，還好自己沒動手瞎忙（無論如何，測試優先讓我重新認識自己的設計，以及目標，于是我義無反顧地拋棄了原來的想法）。新目標出現了，看來我需要一個解析器接口實現的Decorator類（注：這個ResultSet解析器類原本就是一個接口ResultSetParser的實現），我可以先寫一個擴展解析器接口的抽象類來包裝下，以后的Decorator實現都從這個抽象類繼承，直接實現修飾內容就可以了（實際我一直認為，在Decorator模式中所有Decorator實現類都有一個父抽象類繼承自修飾目標類的接口，其最主要的目的是使Decorator實現類功能更清晰，因為實際這個抽象類要包裝的東西其實很少，這些移到子類中也完全可以，這樣的話子類就是直接實現修飾目標類的接口了，效果一樣，所以我認為這里有一個這樣的抽象類統一由所有修飾類繼承，更主要的是宣布，一個修飾目標類接口的實現類它是一個修飾類，這在閱讀程序，以及使用該API上可以達到很好的效果。）。OK，就這么辦（我總是很容易下決定呢，^_^）。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
