BlogJava-庄周梦蝶，孰蝶是我，我是孰蝶？一梦至今，蝶我已难分-随笔分类-设计模式

模块的设计(书摘）

dennis — Sun, 06 Apr 2008 05:00:00 GMT

    模块化的价值毋庸置疑。
    模块化代码的首要特质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其它模块的实现码，也不会胡乱共享全局数据。模块之间通过应用程序编程接口（API）——一组严密、定义良好的程序调用和数据结构来通信。这就是模块化原则的内容。API在模块间扮演双重角色。在实现层面，作为模块之间的滞塞点（choke point），阻止各自的内部细节被相邻模块知晓；在设计层面，正是API(而不是模块间的实现代码)真正定义了整个体系。
    模块的最佳模块大小，逻辑行在200到400之间，物理行在400到800之间为最佳。模块太小，几乎所有的复杂度都集中在接口，同样不利于理解，也就是透明性的欠缺。
   紧凑性就是一个特性能否装进人脑中的特性。理解紧凑性可以从它的“反面”来理解，紧凑性不等于“薄弱”，如果一个设计构建在易于理解且利于组合的抽象概念上，则这个系统能在具有非常强大、灵活的功能的同时保持紧凑。紧凑也不等同于“容易学习”：对于某些紧凑设计而言，在掌握其精妙的内在基础概念模型之前，要理解这个设计相当困难；但一旦理解了这个概念模型，整个视角就会改变，紧凑的奥妙也就十分简单了。紧凑也不意味着“小巧”。即使一个设计良好的系统，对有经验的用户来说没什么特异之处、“一眼”就能看懂，但仍然可能包含很多部分。
    评测一个API紧凑性的经验法则是：API的入口点通常在7个左右，或者按《代码大全2》的说法，7+2和7-2的范围内。
    如果两个或更多事物中的一个发生变化，不会影响其他事物，这些事物就是正交的。每一个动作只改变一件事，不会影响其他（没有其他副作用）。举个例子，比如读取配置文件，获得系统设置信息这个方法：

module Config
   def self.load_config
         config_str=File.open("r","config.xml").read
         #解析配置文件，可能转化成XML Dom处理等

   end
end

这个方法想当然地认为配置文件存储于磁盘文件中，然而配置文件完全是有可能通过网络获取的，也就是说文件句柄未必来源于磁盘文件，这个方法承担了两个职责：获取配置数据和解析配置数据。重构一下，以提高正交性：

module Config
   def self.load_config(io)
         config_str=io.read
         parse_config(config_str)
   end
   private
   def self.parse_config(config_str)
    #解析
   end
end

    重构技术中的很多坏味道，特别是重复代码，是违反正交性的明显例子，“重构的原则性目标就是提高正交性”。
    DRY（Don't Repeat Yourself)原则，意思是说：任何一个知识点在系统内都应当有一个唯一、明确、权威的表述。这个原则的另一种表述就是所谓SPOT原则（Single Point Of Truth）——真理的单点性。
    提高设计的紧凑性，有一个精妙但强大的方法，就是围绕“解决一个定义明确的问题”的强核心算法组织设计，避免臆断和捏造。

dennis 2008-04-06 13:00 发表评论

singleton迷恋

dennis — Sat, 23 Feb 2008 07:34:00 GMT

自从知道singleton模式这把锤子是什么样的之后，我就把很多小疙瘩也当成了钉子，时常想象偶顶着模式的光环挥舞着“万能”锤子在代码丛林中学习兰博搏斗的光辉形象~~~~。昨天读《重构与模式》的inline singleton一节，一句话点醒梦中人，singleton模式是“保证一个类仅有一个实例，并提供一个访问它的全局访问点”，原来——singleton也是全局变量啊。马教主深刻地教育过我们：全局变量在被证明无害之前都是有害。偶大汗淋漓。看看迷恋singleton的几种现象：
1、仅仅在一个地方调用到了某个singleton实例，并且对这个实例的处理代码也集中在这么一两个地方，这样的情况下你为什么要singleton？这里需要一个个全局访问点吗？我看你是为了singleton而singleton。

2、我为了性能优化啊！singleton只有一个实例，减小了创建开销。oh,我终于找到一个用singleton的充分理由了——性能。慢着，跟我读高大师的名言：“不成熟的优化是万恶之源”。你怎么知道singleton对象的重复创建是明显影响了性能？现代jvm对“短命”对象的创建代价已经非常低了。不成熟的优化不仅可能是无效的，而且也给以后重构工作带来了困难。除非有明显数据证明（分析工具而来）某个对象的重复创建是对性能影响极大，否则所谓性能优化不能成为采用singleton模式的理由。

3、有时候我们需要在系统的不同层次间传递一些共享信息，如果不采用singleton对象来提供这些共享信息，就得在调用的方法中重复地传递这些参数，这是个应用singleton模式的场景。但是，如果这些共享信息是可被修改的，或者说singleton对象不是无状态的，如果还采用singleton模式，那么你就不得不在调用的方法中从single对象取出旧信息和存入新信息，这样的重复代码将遍布的到处都是，不仅仅引入了同步访问的需要，而且出错的风险大大提高。这种情况下你还将这些信息作为方法参数传递而不是采用singleton可能更为清晰和健壮。

singleton不仅仅是“保证一个类仅有一个实例”（这仅仅是描述），更重要的是它是用来“提供全局访问点”的（这才是它的功能），不要再迷恋这把锤子，好好利用这把锤子。

题外话：脚本语言似乎更容易滥用全局变量，javascript里可以模拟命名空间，Ruby也可以模拟类似的机制。最近写的一个比较大一点的Ruby脚本，用了几个全局变量（都是数组）用于保存状态数据，一开始没有意识到这一点，导致对全局变量的访问散落在好几个脚本文件里，RDT下看起来红通通的一片极其不爽。那么就重构吧——封装数组重构，将对这些全局数组的访问和修改操作统一到一个模块，调用全局变量的地方都引用这个模块，通过模块去操作全局变量，代码看起来清爽多了。

dennis 2008-02-23 15:34 发表评论

The Future Of the Software Development

dennis — Thu, 25 Oct 2007 02:11:00 GMT

摘要: 在未来，我们可能需要的是一个个高效精干的小型团队，团队成员技艺高超，富于激情，易于沟通。阅读全文

dennis 2007-10-25 10:11 发表评论

谈NullObject模式

dennis — Tue, 31 Jul 2007 09:48:00 GMT

知道这个模式还是通过《重构》，这个模式的出现还是了为了解决代码重复的坏味道。在项目中很经常见到类似下面这样的代码：

if(prj.getProjectId==null)
plan.setCost(0.0);
else
plan.setCost(prj.getCost());

我们在很多地方有类似的检查对象是否为null，如果为null，需要一个默认值等等这样的场景。显然，代码重复是坏味道，怎么消除这个坏味道呢？答案就是使用NullObject替代之，Null Object继承原对象。

class NullProject extends Project{
   public boolean isNull(){
      return true;
   }
}
class Project{
   private double cost;
   private String projectId;
   .
   public boolean isNull(){
        return false;
   }
}

那么，原来的代码可以改写为：

if(prj.isNull())
plan.setCost(0.0);
else
plan.setCost(prj.getCost());

如果Null Object的引入仅仅是带来这个好处，似乎没有理由让我们多敲这么多键盘。问题的关键是类似上面这样的判断也许出现在很多处，那么有价值的技巧出现了，我们在NullObject覆写getCost，提供缺省值：

class NullProject extends Project{
   public boolean isNull(){
      return true;
   }
   public double getCost(){
      return 0.0;
   }
}

因此，检查对象是否为null的代码可以去掉if...else了：

plan.setCost(prj.getCost());

请注意，只有那些大多数客户端代码都要求null object做出相同响应时，这样的行为才有意义。比如我们这里当工程id为null，很多地方要求费用就默认为0.0。特殊的行为我们仍然使用isNull进行判断。
当然，另外在需要返回NullObject的地方，你应该创建一个null object以替代一般的对象，我们可以建立一个工厂方法：

class Project{
   private double cost;
   private String projectId;
   .
   public boolean isNull(){
        return false;
   }
   public Project createNullProject(){
        return new NullProject();
   }
}

Null Object模式带来的好处：减少了检查对象是否为null的代码重复，提高了代码的可读性，通常这些Null Object也可以为单元测试带来简便。

dennis 2007-07-31 17:48 发表评论

JUnit源码分析(四)——从Decorator模式说起

dennis — Fri, 06 Apr 2007 04:39:00 GMT

其实我这系列小文，名为源码分析，其实是自己读《设计模式》的读书笔记。Decorator模式在java的IO库中得到应用，java的IO库看起来复杂，其实理解了Decorator模式再回头看可以很好理解并使用。
Decorator模式，也就是装饰器模式，是对象结构型模式之一。

1.意图：动态地给一个对象添加一些额外的职责。给对象添加功能，我们首先想到的是继承，但是如果每增一个功能都需要继承，类的继承体系将无可避免地变的庞大和难以理解。面向对象设计的原则：优先使用组合，而非继承，继承的层次深度最好不过三。

2.适用场景：
1）在不影响其他对象的情况下，以动态、透明的方式给单个对象添加额外的责任
2）处理可以撤销的职责
3）为了避免类的数目爆炸，或者不能采用生成子类的方法进行扩展时

3.UML图和协作：

Component——定义一个对象接口，可以给这些对象动态地添加职责

ConcreteComponent——定义一个对象，可以给这个对象添加职责

Decorator——维持一个指向Component的引用，并定义一个与Component一致的接口，作为装饰类的父类

ConcreteDecorator——具体装饰类

4.效果：
1）与静态继承相比，Decorator可以动态添加职责，更为灵活
2）避免产生复杂的类，通过动态添加职责，而不是一次性提供一个万能的接口
3）缺点是将产生比较多的小对象，对学习上有难度，显然，java.io就是这个问题

我们以一个例子来实现Decorator模式，假设这样一个场景：在某个应用中需要打印票据，我们写了一个PrintTicket接口，然后提供一个实现类（DefaultPrintTicket）实现打印的功能：

package com.rubyeye.design_pattern.decorator;
//抽象component接口
public interface PrintTicket {
    public void print();
}

//默认实现类，打印票据
package com.rubyeye.design_pattern.decorator;

public class DefaultPrintTicket implements PrintTicket {

    public void print() {
        System.out.println("ticket body");
    }

}

OK,我们的功能已经实现，我们还体现了针对接口编程的原则，替换一个新的打印方式很灵活，但是客户开始提需求了——人生无法避免的三件事：交税、死亡和需求变更。客户要求打印页眉，你首先想到的是继承：

package com.rubyeye.design_pattern.decorator;

public class AnotherPrintTicket implements PrintTicket {

    public void print() {
        System.out.println("ticket header");
        System.out.println("ticket body");
    }

}

请注意，我们这里只是简单的示例，在实际项目中也许意味着添加一大段代码，并且需要修改打印票据本体的功能。需求接踵而至，客户要求添加打印页码，要求增加打印花纹，要求可以联打......你的类越来越庞大，直到你看见这个类都想吐的地步！-_-。让我们看看另一个方案，使用Decorator模式来动态地给打印增加一些功能，首先是实现一个Decorator，它需要保持一个到PrintTicket接口的引用：

package com.rubyeye.design_pattern.decorator;

public class PrintTicketDecorator implements PrintTicket {

    protected PrintTicket printTicket;

    public PrintTicketDecorator(PrintTicket printTicket) {
        this.printTicket = printTicket;
    }

    //默认调用PrintTicket的print
    public void print() {
        printTicket.print();
    }

}

然后，我们实现两个具体的装饰类——打印页眉和页脚：

package com.rubyeye.design_pattern.decorator;

public class HeaderPrintTicket extends PrintTicketDecorator {

    public HeaderPrintTicket(PrintTicket printTicket){
        super(printTicket);
    }

    public void print() {
        System.out.println("ticket header");
        super.print();
    }
}

package com.rubyeye.design_pattern.decorator;

public class FooterPrintTicket extends PrintTicketDecorator {
    public FooterPrintTicket(PrintTicket printTicket) {
        super(printTicket);
    }

    public void print() {
        super.print();
        System.out.println("ticket footer");
    }
}

使用起来也很容易：

package com.rubyeye.design_pattern.decorator;

public class DecoratorTest {

    /**
     * @param args
     */
    public static void main(String[] args) {
        PrintTicket print=new HeaderPrintTicket(new FooterPrintTicket(new DefaultPrintTicket()));
        print.print();
    }

}

输出：
ticket header
ticket body
ticket footer

了解了Decorator模式，我们联系了下JUnit里面的应用。作为一个测试框架，应该方便地支持二次开发，也许用户开发自己的TestCase，添加自定义的功能，比如执行重复测试、多线程测试等等。动态添加职责，而又不想使用静态继承，这正是Decorator使用的地方。在junit.extensions包中有一个TestDecorator，正是所有装饰类的父类，也是作为二次开发的基础，它实现了Test接口，而Test接口就是我们定义的抽象接口：

public class TestDecorator implements  Test {
    //保有一个指向Test的引用
        protected Test fTest;

    public TestDecorator(Test test) {
        fTest= test;
    }

        public void basicRun(TestResult result) {
      fTest.run(result);
        }
        public void run(TestResult result) {
     basicRun(result);
      }

}

Junit已经提供了两个装饰类：junit.extensions.ActiveTest用于处理多线程，junit.extensions.RepeatedTest用于执行重复测试，看看RepeatedTest是怎么实现的：

public class RepeatedTest extends  TestDecorator {
        //重复次数
    private int fTimesRepeat;

    public RepeatedTest(Test test, int repeat) {
        super(test);
        fTimesRepeat= repeat;
    }
        public void run(TestResult result) {
        //重复执行
                for (int i= 0; i < fTimesRepeat; i++) {
            if (result.shouldStop())
                break;
            super.run(result);
        }
    }

}

RepeatedTest继承TestDecorator ，覆写run（TestReult result）方法，重复执行，super.run(result)将调用传入的TestCase的run(TestResult result)方法，这已经在TestDecorator默认实现。看看使用方式，使用装饰模式的好处不言而喻。

TestSuite suite = new TestSuite();
suite.addTest(new TestSetup(new RepeatedTest(new Testmath("testAdd"),12)));

dennis 2007-04-06 12:39 发表评论

JUnit源码分析（三）——Template Method模式

dennis — Fri, 06 Apr 2007 01:54:00 GMT

    在JUnit执行测试时，我们经常需要初始化一些环境供测试代码使用，比如数据库连接、mock对象等等，这些初始化代码应当在每一个测试之前执行并在测试方法运行后清理。在JUnit里面就是相应的setUp和tearDown方法。如果没有这两个方法，那么我们要在每个测试方法的代码内写上一大堆重复的初始化和清理代码，这是多么愚蠢的做法。那么JUnit是怎么让setUp和tearDown在测试执行前后被调用的呢？
    如果你查看下TestCase方法，你会发现TestCase和TestSuite的run()方法都是将执行测试的任务委托给了TestResult，由TestResult去执行测试代码并收集测试过程中的信息（这里用到了Collecting Parameter模式）。

    public TestResult run() {
        TestResult result= createResult();
        run(result);
        return result;
    }
    /**
     * Runs the test case and collects the results in TestResult.
     * This is the template method that defines the control flow
     * for running a test case.
     */
    public void run(TestResult result) {
        result.run(this);
    }

我们直接找到TestResult，看看它的run方法：

/**
     * Runs a TestCase.
     */
    protected void run(final TestCase test) {
        startTest(test);
        Protectable p = new Protectable() {
            public void protect() throws Throwable {
                test.runBare();
            }
        };
        runProtected(test, p);
        endTest(test);
    }

这里实例化了一个内部类，内部类实现了Protectable接口的 protect()方法，并执行传入的TestCase的runBare()方法，显然，真正的测试代码在TestCase的runBare()方法中，让我们来看下：

        //将被子类实现
    protected void setUp() throws Throwable {
    }
    //同上，将被具体的TestCase实现
    protected void tearDown() throws Throwable {
    }
     /**
     * 模板方法
     * Runs the bare test sequence.
     * @exception Throwable if any exception is thrown
     */
    public void runBare() throws Throwable {
        setUp();
        try {
            runTest();
        }
        finally {
            tearDown();
        }
    }

真相水落石出，对于每一个测试方法，都遵循这样的模板：setUp->执行测试 runTest()->tearDown。这正是模板方式模式的一个应用例子。什么是template method模式呢？

Template Method模式

类行为模式的一种
1.意图：定义一个操作中的算法的骨架，而将一些延迟步骤到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些步骤。
2.适用场景：
1）一次性实现算法的不变部分（基本骨架），将可变的行为留给子类来完成
2）子类中的公共部分（比如JUnit中的初始化和清理）被抽取到一个公共父类中以避免代码重复。
3）控制了子类的扩展，这里其实也有类似回调函数的性质，具体步骤先在骨架中注册，在具体执行时被回调。

3.UML图和结构

抽象父类定义了算法的基本骨架（模板方法），而不同的子类实现具体的算法步骤，客户端由此可以与算法的更改隔离。

4.效果：
1）模板方法是代码复用的基本技术，在类库中经常使用，可以减少大量的代码重复
2）通过隔离算法的不变和可变部分，增加了系统的灵活性，扩展算法的某些步骤将变的很容易。

了解了Template Method模式之后，让我们回到JUnit的源码，看看runTest()方法，这里主要应用的是java的反射技术，对于学习反射技术的有参考价值：

protected void runTest() throws Throwable {
        Method runMethod= null;
        try {
            runMethod= getClass().getDeclaredMethod(fName, new Class[0]);
        } catch (NoSuchMethodException e) {
            fail("Method \""+fName+"\" not found");
        }
        if (runMethod != null && !Modifier.isPublic(runMethod.getModifiers())) {
            fail("Method \""+fName+"\" should be public");
        }

        try {
            runMethod.invoke(this, new Class[0]);
        }
        catch (InvocationTargetException e) {
            e.fillInStackTrace();
            throw e.getTargetException();
        }
        catch (IllegalAccessException e) {
            e.fillInStackTrace();
            throw e;
        }
    }

dennis 2007-04-06 09:54 发表评论

JUnit源码分析（二）——观察者模式

dennis — Thu, 05 Apr 2007 09:19:00 GMT

    我们知道JUnit支持不同的使用方式：swt、swing的UI方式，甚至控制台方式，那么对于这些不同的UI我们如何提供统一的接口供它们获取测试过程的信息（比如出现的异常信息，测试成功，测试失败的代码行数等等）？我们试想一下这个场景，当一个error或者exception产生的时候，测试能够马上通知这些UI客户端：发生错误了，发生了什么错误，错误是什么等等。显而易见，这是一个订阅-发布机制应用的场景，应当使用观察者模式。那么什么是观察者模式呢？

观察者模式(Observer)

Observer是对象行为型模式之一

1.意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发现改变时，所有依赖于它的对象都得到通知并被自动更新

2.适用场景：
1）当一个抽象模型有两个方面，其中一个方面依赖于另一个方面，通过观察者模式将这两者封装在不同的独立对象当中，以使它们可以独立的变化和复用
2）当一个对象改变时，需要同时改变其他对象，并且不知道其他对象的具体数目
3）当一个对象需要引用其他对象，但是你又不想让这个对象与其他对象产生紧耦合的时候

3.UML图：

   Subject及其子类维护一个观察者列表，当需要通知所有的Observer对象时调用Nitify方法遍历Observer集合，并调用它们的update方法更新。而具体的观察者实现Observer接口（或者抽象类），提供具体的更新行为。其实看这张图，与Bridge有几分相似，当然两者的意图和适用场景不同。

4.效果：
1）目标和观察者的抽象耦合,目标仅仅与抽象层次的简单接口Observer松耦合，而没有与具体的观察者紧耦合
2）支持广播通信
3）缺点是可能导致意外的更新，因为一个观察者并不知道其他观察者，它的更新行为也许将导致一连串不可预测的更新的行为

5.对于观察者实现需要注意的几个问题：
1）谁来触发更新？最好是由Subject通知观察者更新，而不是客户，因为客户可能忘记调用Notify
2)可以通过显式传参来指定感兴趣的更新
3）在发出通知前，确保Subject对象状态的一致性，也就是Notify操作应该在最后被调用
4）当Subject和Observer的依赖关系比较复杂的时候，可以通过一个更新管理器来管理它们之间的关系，这是与中介者模式的结合应用。

    讨论完观察者模式，那我们来看JUnit是怎么实现这个模式的。在junit.framework包中我们看到了一个Observer接口——TestListener，看看它的代码：

package junit.framework;

/**
* A Listener for test progress
*/
public interface TestListener {
   /**
     * An error occurred.
     */
    public void addError(Test test, Throwable t);
   /**
     * A failure occurred.
     */
     public void addFailure(Test test, Throwable t);
   /**
     * A test ended.
     */
     public void endTest(Test test);
   /**
     * A test started.
     */
    public void startTest(Test test);
}

接口清晰易懂，就是一系列将测试过程的信息传递给观察者的操作。具体的子类将接受这些信息，并按照它们的方式显示给用户。
比如，我们看看swing的UI中的TestRunner，它将这些信息显示在一个swing写的UI界面上：

    public void startTest(Test test) {
        showInfo("Running: "+test);
    }

    public void addError(Test test, Throwable t) {
        fNumberOfErrors.setText(Integer.toString(fTestResult.errorCount()));
        appendFailure("Error", test, t);
    }
    public void addFailure(Test test, Throwable t) {
        fNumberOfFailures.setText(Integer.toString(fTestResult.failureCount()));
        appendFailure("Failure", test, t);
    }
    public void endTest(Test test) {
        setLabelValue(fNumberOfRuns, fTestResult.runCount());
        fProgressIndicator.step(fTestResult.wasSuccessful());
    }

可以看到，它将错误信息，异常信息保存在List或者Vector集合内，然后显示在界面上：

private void showErrorTrace() {
        int index= fFailureList.getSelectedIndex();
        if (index == -1)
            return;

        Throwable t= (Throwable) fExceptions.elementAt(index);
        if (fTraceFrame == null) {
            fTraceFrame= new TraceFrame();
            fTraceFrame.setLocation(100, 100);
           }
        fTraceFrame.showTrace(t);
        fTraceFrame.setVisible(true);
    }
    private void showInfo(String message) {
        fStatusLine.setFont(PLAIN_FONT);
        fStatusLine.setForeground(Color.black);
        fStatusLine.setText(message);
    }
    private void showStatus(String status) {
        fStatusLine.setFont(BOLD_FONT);
        fStatusLine.setForeground(Color.red);
        fStatusLine.setText(status);
    }

而Junit中的目标对象(Subject）就是TestResult对象，它有添加观察者的方法：

/**
     * Registers a TestListener
     */
    public synchronized void addListener(TestListener listener) {
        fListeners.addElement(listener);
    }

而通知观察者又是怎么做的呢？请看这几个方法，都是循环遍历观察者列表，并调用相应的更新方法：

/**
     * Adds an error to the list of errors. The passed in exception caused the
     * error.
     */
    public synchronized void addError(Test test, Throwable t) {
        fErrors.addElement(new TestFailure(test, t));
        for (Enumeration e = fListeners.elements(); e.hasMoreElements();) {
            ((TestListener) e.nextElement()).addError(test, t);
        }
    }

    /**
     * Adds a failure to the list of failures. The passed in exception caused
     * the failure.
     */
    public synchronized void addFailure(Test test, AssertionFailedError t) {
        fFailures.addElement(new TestFailure(test, t));
        for (Enumeration e = fListeners.elements(); e.hasMoreElements();) {
            ((TestListener) e.nextElement()).addFailure(test, t);
        }
    }

    /**
     * Registers a TestListener
     */
    public synchronized void addListener(TestListener listener) {
        fListeners.addElement(listener);
    }

    /**
     * Informs the result that a test was completed.
     */
    public synchronized void endTest(Test test) {
        for (Enumeration e = fListeners.elements(); e.hasMoreElements();) {
            ((TestListener) e.nextElement()).endTest(test);
        }
    }

使用这个模式后带来的好处：
1)上面提到的Subject与Observer的抽象耦合，使JUnit可以支持不同的使用方式
2）支持了广播通信，目标对象不关心有多少对象对自己注册，它只是通知注册的观察者

最后，我实现了一个简单的ConsoleRunner，在控制台执行JUnit,比如我们写了一个简单测试：

package junit.samples;

import junit.framework.*;

/**
* Some simple tests.
*
*/
public class SimpleTest extends TestCase {
    protected int fValue1;

    protected int fValue2;

    public SimpleTest(String name) {
        super(name);
    }

    public void setUp() {
        fValue1 = 2;
        fValue2 = 3;
    }

    public void testAdd() {
        double result = fValue1 + fValue2;
        assert(result == 5);
    }

    public void testEquals() {
        assertEquals(12, 12);
        assertEquals(12L, 12L);
        assertEquals(new Long(12), new Long(12));

        assertEquals("Size", 12, 12);
        assertEquals("Capacity", 12.0, 11.99, 0.01);
    }
}

使用ConsoleRunner调用这个测试，代码很简单，不多做解释了：

package net.rubyeye.junit.framework;

import java.lang.reflect.Method;
import java.util.ArrayList;
import java.util.List;
import java.util.Vector;

import junit.framework.Test;
import junit.framework.TestListener;
import junit.framework.TestResult;
import junit.samples.SimpleTest;
//实现观察者接口
public class ConsoleRunner implements TestListener {

    private TestResult fTestResult;

    private Vector fExceptions;

    private Vector fFailedTests;

    private List fFailureList;

    public ConsoleRunner() {
        fExceptions = new Vector();
        fFailedTests = new Vector();
        fFailureList = new ArrayList();
    }

    public void endTest(Test test) {
        System.out.println("测试结束：");
        String message = test.toString();
        if (fTestResult.wasSuccessful())
            System.out.println(message + " 测试成功!");
        else if (fTestResult.errorCount() == 1)
            System.out.println(message + " had an error");
        else
            System.out.println(message + " had a failure");

        for (int i = 0; i < fFailureList.size(); i++) {
            System.out.println(fFailureList.get(i));
        }
        for (int i = 0; i < fFailedTests.size(); i++) {
            System.out.println(fFailureList.get(i));
        }
        for (int i = 0; i < fExceptions.size(); i++) {
            System.out.println(fFailureList.get(i));
        }

        System.out.println("------------------------");
    }

    public void startTest(Test test) {
        System.out.println("开始测试:" + test);
    }

    public static TestResult createTestResult() {
        return new TestResult();
    }

    private String truncateString(String s, int length) {
        if (s.length() > length)
            s = s.substring(0, length) + "";
        return s;
    }

    public void addError(Test test, Throwable t) {
        System.out.println(fTestResult.errorCount());
        appendFailure("Error", test, t);
    }

    public void addFailure(Test test, Throwable t) {
        System.out.println(fTestResult.failureCount());
        appendFailure("Failure", test, t);
    }

    private void appendFailure(String kind, Test test, Throwable t) {
        kind += ": " + test;
        String msg = t.getMessage();
        if (msg != null) {
            kind += ":" + truncateString(msg, 100);
        }
        fFailureList.add(kind);
        fExceptions.addElement(t);
        fFailedTests.addElement(test);
    }

    public void go(String args[]) {
        Method[] methods = SimpleTest.class.getDeclaredMethods();

        for (int i = 0; i < methods.length; i++) {
            //取所有以test开头的方法
            if (methods[i].getName().startsWith("test")) {
                Test test = new SimpleTest(methods[i].getName());
                fTestResult = createTestResult();
                fTestResult.addListener(ConsoleRunner.this);
                //执行测试
                test.run(fTestResult);
            }
        }

    }

    public static void main(String args[]) {
        new ConsoleRunner().go(args);
    }

}

dennis 2007-04-05 17:19 发表评论

JUnit源码分析（一）——Command模式和Composite模式

dennis — Thu, 05 Apr 2007 07:10:00 GMT

    JUnit的源码相比于spring和hibernate来说比较简单，但麻雀虽小，五脏俱全，其中用到了比较多的设计模式。很多人已经在网上分享了他们对JUnit源码解读心得，我这篇小文谈不出什么新意，本来不打算写，可最近工作上暂时无事可做，那就写写吧，结合《设计模式》来看看。
    我读的是JUnit3.0的源码，目前JUnit已经发布到4.0版本了，尽管有比较大的改进，但基本的骨架不变，读3.0是为了抓住重点，省去对旁支末节的关注。我们来看看JUnit的核心代码，也就是Junit.framework包，除了4个辅助类（Assert,AssertFailedError,Protectable,TestFailure），剩下的就是我们需要重点关注的了。我先展示一张UML类图：

    我们先不去关注TestDecorator类（此处是Decorator模式，下篇文章再讲），看看Test接口，以及它的两个实现类TestCase和TestSuite。很明显，此处用到了Command模式，为什么要使用这个模式呢？让我们先来看看什么是Command模式。

Command模式

Command模式是行为型模式之一

1.意图：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。
2.适用场景：
1）抽象出待执行的动作以参数化对象，Command模式是回调函数的面向对象版本。回调函数，我想大家都明白，函数在某处注册，然后在稍后的某个时候被调用。
2）可以在不同的时刻指定、排列和执行请求。
3）支持修改日志，当系统崩溃时，这些修改可以被重做一遍。
4）通过Command模式，你可以通过一个公共接口调用所有的事务，并且也易于添加新的事务。

3。UML图：


4.效果：
1）命令模式将调用操作的对象与如何实现该操作的对象解耦。
2）将命令当成一个头等对象，它们可以像一般对象那样进行操纵和扩展
3）可以将多个命令复合成一个命令，与Composite模式结合使用
4）增加新的命令很容易，隔离对现有类的影响
5）可以与备忘录模式配合，实现撤销功能。

    在了解了Command模式之后，那我们来看JUnit的源码，Test接口就是命令的抽象接口，而TestCase和TestSuite是具体的命令

//抽象命令接口
package junit.framework;

/**
* A Test can be run and collect its results.
*
* @see TestResult
*/
public interface Test {

    /**
     * Counts the number of test cases that will be run by this test.
     */
    public abstract int countTestCases();
    /**
     * Runs a test and collects its result in a TestResult instance.
     */
    public abstract void run(TestResult result);
}

//具体命令一

public abstract class TestCase extends Assert implements Test {
    /**
     * the name of the test case
     */
    private final String fName;
    /**


//具体命令二

public class TestSuite implements Test {

由此带来的好处：
1.客户无需使用任何条件语句去判断测试的类型，可以用统一的方式调用测试和测试套件，解除了客户与具体测试子类的耦合
2.如果要增加新的TestCase也很容易，实现Test接口即可，不会影响到其他类。
3.很明显，TestSuite是通过组合多个TestCase的复合命令，这里使用到了Composite模式（组合）
4.尽管未实现redo和undo操作，但将来也很容易加入并实现。

    我们上面说到TestSuite组合了多个TestCase，应用到了Composite模式，那什么是Composite模式呢？具体来了解下。

Composite模式

composite模式是对象结构型模式之一。
1.意图：将对象组合成树形结构以表示“部分——整体”的层次结构。使得用户对单个对象和组合结构的使用具有一致性。

2.适用场景：
1）想表示对象的部分-整体层次
2）希望用户能够统一地使用组合结构和单个对象。具体到JUnit源码，我们是希望用户能够统一地方式使用TestCase和TestSuite

3.UML图：



图中单个对象就是树叶（Leaf），而组合结构就是Compoiste，它维护了一个Leaf的集合。而Component是一个抽象角色，给出了共有接口和默认行为，也就是JUnit源码中的Test接口。

4.效果：
1）定义了基本对象和组合对象的类层次结构，通过递归可以产生更复杂的组合对象
2）简化了客户代码，客户可以使用一致的方式对待单个对象和组合结构
3）添加新的组件变的很容易。但这个会带来一个问题，你无法限制组件中的组件，只能靠运行时的检查来施加必要的约束条件

    具体到JUnit源码，单个对象就是TestCase，而复合结构就是TestSuite，Test是抽象角色只有一个run方法。TestSuite维护了一个TestCase对象的集合fTests：

     private Vector fTests= new Vector(10);
      /**
     * Adds a test to the suite.
     */
    public void addTest(Test test) {
        fTests.addElement(test);
    }
    /**
     * Runs the tests and collects their result in a TestResult.
     */
    public void run(TestResult result) {
        for (Enumeration e= tests(); e.hasMoreElements(); ) {
              if (result.shouldStop() )
                  break;
            Test test= (Test)e.nextElement();
            test.run(result);
        }
    }

当执行run方法时遍历这个集合，调用里面每个TestCase对象的run()方法，从而执行测试。我们使用的时候仅仅需要把TestCase添加到集合内，然后用一致的方式（run方法）调用他们进行测试。

考虑使用Composite模式之后带来的好处：
1）JUnit可以统一地处理组合结构TestSuite和单个对象TestCase，避免了条件判断，并且可以递归产生更复杂的测试对象
2）很容易增加新的TestCase。

参考资料：《设计模式——可复用面向对象软件的基础》
          《JUnit设计模式分析》刘兵
          JUnit源码和文档

dennis 2007-04-05 15:10 发表评论