这个时候我有两个选择，一是直接就写代码，一是先写个测试。当然，我选择的是先写个测试，之所以摆明了这二个当然是为了比较了。先说如果我先写代码，那么我就直接进入了目标功能的角色，因为现在似乎目标很明确，我要给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，就这么办（我总是很容易下决定呢，^_^）。
文章来源于领测软件测试网 https://www.ltesting.net/
