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 发表评论

创建型模式摘记

dennis — Sat, 17 Mar 2007 09:01:00 GMT

系统的演化应当依赖于组合，而不是继承；这就提出了将类的实例化委托给一个对象的要求，因此创建型模式将变的越来越重要。

创建型模式属于对象创建模型。所谓对象创建模型就是说将实例化的工作委托给另一个对象来做。与之相对应的是类创建模型，这是一种通过继承改变被实例化的类。

创建型模式有两个重要的特点：

1）客户不知道创建的具体类是什么（除非看源代码）

2）隐藏了类的实例是如何被创建和放在一起的

一。抽象工厂模式
1.意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们的具体的类。
2.适用场景：
1)一个系统要独立于它的产品的创建、组合和表示时
2）一个系统要由多个产品系列中的一个来配置时
3）当你要强调一系列相关的产品对象的设计以便进行联合使用时
4）当你提供一个产品类库，而只想显示它们的接口而不是实现时

3.UML图——结构

4.效果：
1）分离了具体的类，通过抽象接口将客户与具体的类分离
2）易于交换产品系列
3）有利于产品的一致性
4）难以支持新种类的产品，比如我们现在有一个ProductC产品，我们需要增加类AbstractProductC，增加AbstractFactory:: CreanteProductC方法，并且两个产品系列的实际创建者ConCreateFactory1、ConCreateFactor2都要实现该方法。

可以通过给方法加参数的方式来指明创建的是什么产品，这样客户代码就无需改变，只要传递不同的参数。AbstractFactory类只需要提供一个CreateProduct(const string& name)方法即可。

5.代码实现，以《深入浅出设计模式(java C#)》的动物工厂为例：

using System;
namespace AnimalWorld
{
    // 抽象大陆工厂
    abstract class ContinentFactory
    {
        abstract public Herbivore CreateHerbivore();
        abstract public Carnivore CreateCarnivore();
    }
    //非洲大陆,有角马，狮子
    class AfricaFactory : ContinentFactory
    {
        override public Herbivore CreateHerbivore()
        {
            return new Wildebeest();
        }
        override public Carnivore CreateCarnivore()
        {
            return new Lion();
        }
    }
    // 美洲大陆,有狼,野牛
    class AmericaFactory : ContinentFactory
    {
        override public Herbivore CreateHerbivore()
        {
            return new Bison();
        }
        override public Carnivore CreateCarnivore()
        {
            return new Wolf();
        }
    }
    //食草动物"
    abstract class Herbivore
    {
    }
    //肉食动物"
    abstract class Carnivore
    {
        //猎食食草动物的方法
        abstract public void Eat( Herbivore h );
    }
    //角马
    class Wildebeest : Herbivore
    {
    }
    //狮子"
    class Lion : Carnivore
    {
        //重载猎食食草动物的方法
        override public void Eat( Herbivore h )
        {
            Console.WriteLine( this + " eats " + h );
        }
    }
    //野牛
    class Bison : Herbivore
    {
    }
    //狼
    class Wolf : Carnivore
    {
        //重载猎食食草动物的方法
        override public void Eat( Herbivore h )
        {
            Console.WriteLine( this + " eats " + h );
        }
    }
    //动物世界类
    class AnimalWorld
    {
        private Herbivore herbivore;
        private Carnivore carnivore;
        // 创建两种动物分类
        public AnimalWorld( ContinentFactory factory )
        {
            carnivore = factory.CreateCarnivore();
            herbivore = factory.CreateHerbivore();
        }
        //运行食物链
        public void RunFoodChain()
        {
            //肉食动物猎食食草动物
            carnivore.Eat( herbivore );
        }
    }
    ///

/// 抽象工厂模式客户应用测试
///

    class GameApp
    {
        [STAThread]
        static void Main(string[] args)
        {
            //创造并运行非洲动物世界
            ContinentFactory africa = new AfricaFactory();
            AnimalWorld world = new AnimalWorld( africa );
            world.RunFoodChain();
            //创造并运行美洲动物世界
            ContinentFactory america = new AmericaFactory();
            world = new AnimalWorld( america );
            world.RunFoodChain();
            Console.Read();
        }

    }
}

二。Builder模式
1.意图：将一个复杂对象的构建与它的表示相分离，使得同样的构建过程可以创建不同的表示（或者说产品）

2.适用场景：
1）当创建复杂对象的算法应该独立于改对象的组成部分以及它们的装配方式时
2）当构造过程必须允许被构造的对象有不同的表示时

3.UML图——结构

Director接受一个Builder子类对象，完成创建过程，并通知Builder对象返回以及构造好的产品。

4.效果：
1）可以使你改变一个对象的内部表示
2）构造代码和表示代码分开
3）可以对构造过程进行更精细的控制

5。实现：以一个车辆建造过程为例（C#)

using System;

namespace CarShop
{
    using System;
    using System.Collections;
    //指挥者,Director
    class Shop{
        public void Construct( VehicleBuilder vehicleBuilder ){
            vehicleBuilder.BuildFrame();
            vehicleBuilder.BuildEngine();
            vehicleBuilder.BuildWheels();
            vehicleBuilder.BuildDoors();
        }
    }
    /* "Builder 建造者",Builder
    抽象建造者具有四种方法
    装配框架
    装配发动机
    装配轮子
    装配车门
    */
    abstract class VehicleBuilder
    {
        protected Vehicle vehicle;
        //返回建造完成的车辆
        public Vehicle Vehicle{
            get{ return vehicle; }
        }
        abstract public void BuildFrame();
        abstract public void BuildEngine();
        abstract public void BuildWheels();
        abstract public void BuildDoors();
    }
    //具体建造者-摩托车车间
    class MotorCycleBuilder : VehicleBuilder
    {
        override public void BuildFrame(){
            vehicle = new Vehicle( "摩托车" );
            vehicle[ "frame" ] = "MotorCycle Frame";
        }

        override public void BuildEngine(){
            vehicle[ "engine" ] = "500 cc";
        }

        override public void BuildWheels(){
            vehicle[ "wheels" ] = "2";
        }

        override public void BuildDoors(){
            vehicle[ "doors" ] = "0";
        }
    }
    //具体建造者-轿车车间
    class CarBuilder : VehicleBuilder
    {
        override public void BuildFrame(){
            vehicle = new Vehicle( "轿车" );
            vehicle[ "frame" ] = "Car Frame";
        }
        override public void BuildEngine(){
            vehicle[ "engine" ] = "2500 cc";
        }
        override public void BuildWheels(){
            vehicle[ "wheels" ] = "4";
        }
        override public void BuildDoors(){
            vehicle[ "doors" ] = "4";
        }
    }
    // 具体建造者-单脚滑行车车间
    class ScooterBuilder : VehicleBuilder
    {
        override public void BuildFrame(){
            vehicle = new Vehicle( "单脚滑行车" );
            vehicle[ "frame" ] = "Scooter Frame";
        }

        override public void BuildEngine(){
            vehicle[ "engine" ] = "none";
        }

        override public void BuildWheels(){
            vehicle[ "wheels" ] = "2";
        }

        override public void BuildDoors(){
            vehicle[ "doors" ] = "0";
        }
    }
    //车辆产品类
    class Vehicle
    {
        private string type;
        private Hashtable parts = new Hashtable();
        //筑构函数,决定类型
        public Vehicle( string type ){
            this.type = type;
        }
        //索引
        public object this[ string key ]{
            get{ return parts[ key ]; }
            set{ parts[ key ] = value; }
        }
        //显示方法
        public void Show()
        {
            Console.WriteLine( "\n---------------------------");
            Console.WriteLine( "车辆类类型: "+ type );
            Console.WriteLine( " 框架 : " + parts[ "frame" ] );
            Console.WriteLine( " 发动机 : "+ parts[ "engine"] );
            Console.WriteLine( " #轮子数: "+ parts[ "wheels"] );
            Console.WriteLine( " #车门数 : "+ parts[ "doors" ] );
        }
    }
    ///

/// 建造者模式应用测试
///

     class CarShop
    {
        [STAThread]
        static void Main(string[] args)
        {
            // 创造车间及车辆建造者
            Shop shop = new Shop();
            VehicleBuilder b1 = new ScooterBuilder();
            VehicleBuilder b2 = new CarBuilder();
            VehicleBuilder b3 = new MotorCycleBuilder();
            // 筑构并显示车辆
            shop.Construct( b1 );
            b1.Vehicle.Show();
            shop.Construct( b2 );
            b2.Vehicle.Show();
            shop.Construct( b3 );
            b3.Vehicle.Show();
            Console.Read();

        }
    }
}

三。Factory Method模式
1.意图：定义一个用于创建对象的接口，让子类决定实例化具体的哪一个类。
2.适用场景：
1）当一个类不知道它所必须创建的对象的类的时候，让子类来决定
2）当一个类希望由它的子类来决定它所创建的对象的时候

3。UML图——结构：

4.效果：
1）为子类提供回调函数
2）连接平行的类层次

3）创建函数可以接收参数来决定创建什么产品

4）Factory Method容易导致创建过多的Creator的子类以对应不同的产品，这个方法可以通过模板技术来解决

6.实现，手机工厂，产品可能是Nokia，也可能是Motorola

using System;
using System.Collections.Generic;
using System.Text;

namespace HandPhone
{
    //手机接口
    interface Mobile
    {
         void call();
    }

    //手机工厂接口
    interface MobileFactory
    {
          Mobile createMobile();
    }

    //Nokia
    class Nokia:Mobile
    {
        public void call()
        {
            Console.WriteLine("This is a {0} phone", this.GetType().Name);
        }
    }

    //Motorola
    class Motorola : Mobile
    {
        public void call()
        {
            Console.WriteLine("This is a {0} phone", this.GetType().Name);
        }
    }

    //Motorola工厂
    class MotorolaFactory : MobileFactory
    {
         public Mobile createMobile()
        {
            return new Motorola();
        }
    }

    //Nokia工厂
    class NokiaFactroy : MobileFactory
    {
        public Mobile createMobile()
        {
            return new Nokia();
        }
    }

    public class Client
    {
        static void Main(String []args)
        {
            MobileFactory factory=null;
            Mobile mobile=null;

            factory=new NokiaFactroy();
            mobile=factory.createMobile();
            mobile.call();

            factory=new MotorolaFactory();
            mobile=factory.createMobile();
            mobile.call();

        }
    }

}

四。Prototype模式

1.意图：通过原型实例指定创建对象的种类，并通过拷贝这些原型来创建新的对象

2.适用场景：
1）要实例化的类是在运行时刻指定的，比如动态装载
2）为了避免创建一个与产品层次平行的工厂类层次
3）当一个类的实例只能有几个不同的状态组合中的一种时，建立相应数目的原型并克隆它们可能比每次用合适的状态手工化该类更方便一些。

3.UML图——结构：

4.效果：
1）运行时动态增加或者删除产品
2）减少子类的构造数目
3）用类动态配置应用
4）动态指定新的对象，通过改变结构或者值
5）缺陷在于每一个Prototype的子类都需要实现clone操作

5。实现,无论java还是C#都从语言层次内置了对prototype模式的支持。具体不再详述。

五。singleton模式
1。意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点

2.适用场景：
1）当需要类只有一个实例，并且客户只能通过一个全局点去访问它
2）当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用扩展的实例

3.UML图：略

4.效果：
1）对唯一实例的受控访问
2）缩小命名空间
3）允许对操作和表示的细化
4）允许可变数目的实例

5实现，关于singleton在java多线程环境下的实现，请见讨论《当Singleton遇到multi-threading》，C#对singleton多线程环境下的能够正确实现Double-checked模式：

public sealed class Singleton
{
    private static volatile Singleton instance;
    private static object syncRoot = new Object();

    private Singleton() {}

    public static Singleton Instance
    {
        get
        {
            if (instance == null)
            {
                lock (syncRoot)
                {
                    if (instance == null)
                        instance = new Singleton();
                }
            }

            return instance;
        }
    }
}

本文仅作速查记忆用，摘记于《设计模式——可复用面向对象软件基础》和《深入浅出设计模式（java C#)》两书

dennis 2007-03-17 17:01 发表评论

《设计模式精解》读后感

dennis — Sat, 03 Mar 2007 02:41:00 GMT

    模式一直是J2EE领域的热门话题。两年前，对刚开始自学java并且到处碰壁的我，一本在图书馆借的《java与模式》看的我云里雾里，尽管心里面觉的他讲的很有道理，可对于没有实际项目经验的我，真正的理解和应用还很远很远。转眼工作快一年多了了，也做了几个不大不小的项目，尽管还只是个代码工人水准的，但是对于模式的兴趣越发浓厚，于是从书堆里找出来买了好久的GOF《设计模式》。这本书是圣经级别了，可我对C++的了解有限（虽然在学校里还是狠狠啃过好几本大部头，现在忘光了），而且这本圣经对初学者似乎不太友好，对模式也以罗列各条目为主，例子失当。于是买了《设计模式精解》，看china-pub的书评都说对初学者很有用，而且翻译的人也是我很佩服的gigix。
    在春节期间读完了这本书，本书详细介绍了13种常见的设计模式，以一个实际问题引出了对面向对象新观点和设计模式的讨论，在介绍完所有的模式后，更难能可贵的是作者详细介绍了自己对模式的使用经验（使用共同点/变化点分析，使用分析矩阵等），整本书读下来令人心旷神怡。
我们为什么要学习设计模式呢？总之是为了获得可以复用和容易扩展的解决方案，建立通用术语以方便团队内的沟通交流，另外，模式能让你以更高的层次或者说视角去观察问题，这样的视角将你从过早处理细节的泥潭中解放出来。模式本身就是对如何创建优良面向对象设计策略的实现：
    1.针对接口编程
    2.优先使用对象组合，而不是类继承
    3.发现并封装变化点
    你可以在每一个模式的背后或者每一个优秀设计的背后看到这些原则的影子。比如abstract factory、adapter、strategy体现了针对接口编程，composite、bridge体现了优先使用组合而不是继承等。

    作者解释了面向对象的新观点:

                原来的观点                新的观点

对象           伴随有方法的数据            拥有责任的实体，或者说拥有特定行为的实体

封装          数据隐藏    各种形式的封装，1.数据的封装，2.方法的封装
   3.父类对子类的隐藏   4.其他对象的封装

继承    特化和复用对象分类的一种方法

    这些观点其实并不新，Martin Fowler提出了软件开发过程中的三种视觉：概念、规格和实现，过去我们对面向对象的观点来自于实现的角度(代码的角度）去观察，而新的观点只是从概念的角度重新观察面向对象设计。
    深入到具体模式的讨论，记录一些需要注意的问题：
1.Adapter与Facade模式的区别
它们都是包装器，但是两者也有细微的区别:
.两个模式中，我们都有已经存在的类（或者说系统）
.Facade模式中，我们无需针对接口编程；而Adapter模式我们必须针对接口编程
.Adapter模式通常是为了保持多态，而Facade模式对此不感兴趣
.动机不同，Facade模式是为了简化接口，而Adapter模式是针对一个现存的接口编程
结论：Facade模式简化接口，而Adapter模式将接口转换成另一个现有的接口

2.Bridge模式的理解
Bridge模式的意图是将抽象部分与它的实现部分分离，使它们可以独立的变化。这里的关键点是需要理解“实现部分”，如果把“实现部分”看成“对象外部、被对象使用的某种东西”，此模式就很好理解了。我们将变化转移到一个使用或者拥有变化的对象（此对象是指抽象类的对象和用来实现抽象类的派生类的对象）。当出现继承的类爆炸情况时，也许你该考虑此模式的应用场景了。此模式的UML图

3.Observer模式，实现自己的观察者模式也是很简单，不过java已经内置了对此模式的支持。java.util.Observer和java.util.Observable是此模式的一个实现版本，实际应用中你所需要做的只是实现Observer接口，和继承Observable类

4.Decorator模式是为现有的功能动态添加附加功能的一种方法，UML图如下

java的IO库是典型的应用实现，java.io.InputStream和java.io.OutputStream就是图中的Component接口，FilterInputStream继承InputStream（也就是图中的Decorator，装饰器），其他的如ByteArrayInputStream、FileInputStream等直接继承自InputStream的类就是被装饰对象，而继承FilterInputStream的就是各式各样的装饰者。

5.Strategy模式是一种定义算法家族的方法，所有的算法都做相同的工作，它们只是拥有不同的实现。当你的代码中出现了很多switch或者if else的语句，你应该考虑此模式。Strategy模式带来的缺点是类的数量的增加，在java中可以通过将实现类作为嵌套类放在Strategy抽象类中来解决。

6.singleton模式的实现
单线程应用：
第一种：静态初始化

public class Singleton {
    private Singleton() {
    }

    private static Singleton instance = new Singleton();

    public static Singleton getInstance() {
        return instance;
    }
}

第二种：lazy loading

public   class   Singleton   {
  　　private   static   Singleton   instance   =   null;

  　　public   static   Singleton   getInstance()   {

  　　if   (instance==null)
  　　　　instance＝new   Singleton();
  　　return   instance;   　　}

  }

多线程环境下：在C++中安全的Double-Checked Locking模式，在java中是不安全的，详细原因与java的内存管理模型有关，请见dreamstone的文章《java中的模式——单态》
安全的实现方法是使用同步：

   public class Singleton {

   static Singleton instance;

      public static synchronized Singleton getInstance() {
        if (instance == null)
          instance == new Singleton();
        return instance;
      }

}

《Effective Java》中提到的另一种写法

public class Singleton {

  static class SingletonHolder {
    static Singleton instance = new Singleton();
  }

  public static Singleton getInstance() {
    return SingletonHolder.instance;
  }

}

    在介绍完13个模式之后，作者提出了一种称为分析矩阵的方法，详细讨论不是这篇短文能说的完，有兴趣请找来此书的电子版看看。简单来讲，先从问题领域中分析出所有的变化点和共同点，观察每一种必须实现的功能并作为矩阵的行，而矩阵中的列表示特定情况中的特定实现；然后观察行，并根据场景探讨使用合适的模式；最后观察列，从整体上考虑整个问题的模式的使用。在出现的概念的场景中添加新的概念来进行设计。

    最后，作者总结了面向对象的原则：
.“对象”是负有定义良好的责任的东西
.对象对自己负责
.封装意味着
——数据隐藏
——类隐藏（藏在抽象类或者接口后面）
——实现隐藏（变化封装为对象进行引用）
.使用共同点/变化点分析抽象出行为和数据中的变化点
.针对接口编程
.把继承考虑为一种封装变化的方法，而不是为现有的对象制造特殊情况
.将变化点封装在一个类中，并使之与其他变化点相分离
.力求松耦合
.力求高内聚
.绝对细心地应用“一次并且只有一次”规则（只在一个地方实现一条规则）
   书本只是提供了模式的介绍和参照，真正的应用还是要靠自己日常工作中的观察和体验，我将继续在工作中理解并贯彻这些原则。

dennis 2007-03-03 10:41 发表评论

使用Annotation设计持久层

dennis — Tue, 06 Feb 2007 04:24:00 GMT

这篇文章的想法来自于过去的两篇文章：《设计自己的MVC框架》《设计模式之事务处理》
链接：
http://www.javaresearch.org/article/59935.htm
http://www.javaresearch.org/article/59043.htm

代码下载同样在www.126.com的邮箱里，用户名 sharesources 密码 javafans

    本文只是学习性质的文章，我一开始的想法就是修改《设计模式之事务处理》，提供Annotation来提供事务支持，支持到方法级别。通过引入一个 @Transaction标注，如果被此标注的方法将自动享受事务处理。目的是学习下Annotation和加深下对声明式事务处理的理解。

    Annotation是JDK5引入的新特性，现在越来越多的框架采用此特性来代替烦琐的xml配置文件，比如hibernate,ejb3, spring等。对Annotation不了解，请阅读IBM网站上的文章，还有推荐javaeye的Annotation专栏：http: //www.javaeye.com/subject/Annotation

    代码的示例是一个简单的用户管理例子。

    首先，环境是mysql+jdk5+myeclipse5+tomcat5，在mysql中建立一张表adminusers:
    create table adminusers(id int(10) auto_increment not null primary key,
     name varchar(10) not null,
     password varchar(10) not null,
     user_type varchar(10));
    然后在tomcat下建立一个数据源，把代码中的strutslet.xml拷贝到tomcat安装目录下的 /conf/Catalina/localhost目录里，请自行修改文件中的数据库用户名和密码，以及数据库名称。另外，把mysql的 jdbc驱动拷贝到tomcat安装目录下的common/lib目录。这样数据源就建好了。在web.xml中引用：

DB Connection

jdbc/test

javax.sql.DataSource

Container

    我的例子只是在《设计模式之事务处理》的基础上改造的，在那篇文章里，我讲解了自己对声明式事务处理的理解，并利用动态代理实现了一个 TransactionWrapper(事务包装器)，通过业务代理工厂提供两种版本的业务对象：经过事务包装的和未经过事务包装的。我们在默认情况下包装业务对象中的所有方法，但实际情况是，业务对象中的很多方法不用跟数据库打交道，它们根本不需要包装在一个事务上下文中，这就引出了，我们为什么不提供一种方式来配置哪些方法需要事务控制而哪些并不需要？甚至提供事务隔离级别的声明？很自然的想法就是提供一个配置文件，类似spring式的事务声明。既然JDK5已经引入Annotation，相比于配置文件的烦琐和容易出错，我们定义一个@Transaction的annotation来提供此功能。

    看下Transaction.java的代码：
    package com.strutslet.db;

    import java.lang.annotation.Documented;
    import java.lang.annotation.ElementType;
    import java.lang.annotation.Retention;
    import java.lang.annotation.RetentionPolicy;
    import java.lang.annotation.Target;
    import java.sql.Connection;

    @Target(ElementType.METHOD)
    @Retention(RetentionPolicy.RUNTIME)
    @Documented
    public @interface Transaction {
   //事务隔离级别，默认为read_committed
       public int level() default Connection.TRANSACTION_READ_COMMITTED    ;
    }

@Transaction 标注只有一个属性level，level表示事务的隔离级别，默认为Read_Committed（也是一般JDBC驱动的默认级别，JDBC驱动默认级别一般于数据库的隔离级别一致）。 @Target(ElementType.METHOD)表示此标注作用于方法级别， @Retention(RetentionPolicy.RUNTIME)表示在运行时，此标注的信息将被加载进JVM并可以通过Annotation的 API读取。我们在运行时读取Annotation的信息，根据隔离级别和被标注的方法名决定是否将业务对象的方法加进事务控制。我们只要稍微修改下 TransactionWrapper:

//TransactionWrapper.java
package com.strutslet.db;

import java.lang.annotation.Annotation;
import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;
import java.sql.Connection;
import java.sql.SQLException;

import com.strutslet.exception.SystemException;

public class TransactionWrapper {


    public static Object decorate(Object delegate) {
        return Proxy.newProxyInstance(delegate.getClass().getClassLoader(),
                delegate.getClass().getInterfaces(), new XAWrapperHandler(
                        delegate));
    }

    static final class XAWrapperHandler implements InvocationHandler {
        private final Object delegate;

        XAWrapperHandler(Object delegate) {
            // Cache the wrapped delegate, so we can pass method invocations
            // to it.
            this.delegate = delegate;
        }

        public Object invoke(Object proxy, Method method, Object[] args)
                throws Throwable {
            Object result = null;
            Connection con = ConnectionManager.getConnection();
            //得到Transaction标注
            Transaction transaction = method.getAnnotation(Transaction.class);

            //如果不为空，说明代理对象调用的方法需要事务控制。
            if (transaction != null) {
                // System.out.println("transaction.." + con.toString());
                // 得到事务隔离级别信息
                int level = transaction.level();
                try {
                    if (con.getAutoCommit())
                        con.setAutoCommit(false);
                    //设置事务隔离级别
                    con.setTransactionIsolation(level);
                    //调用原始对象的业务方法
                    result = method.invoke(delegate, args);
                    con.commit();
                    con.setAutoCommit(true);
                } catch (SQLException se) {
                    // Rollback exception will be thrown by the invoke method
                    con.rollback();
                    con.setAutoCommit(true);
                    throw new SystemException(se);
                } catch (Exception e) {
                    con.rollback();
                    con.setAutoCommit(true);
                    throw new SystemException(e);
                }
            } else {
                result = method.invoke(delegate, args);
            }

            return result;
        }
    }
}

现在，看下我们的UserManager业务接口，请注意，我们是使用动态代理，只能代理接口，所以要把@Transaction标注是接口中的业务方法（与EJB3中的Remote,Local接口类似的道理）:
package com.strutslet.demo.service;

import java.sql.SQLException;

import com.strutslet.db.Transaction;
import com.strutslet.demo.domain.AdminUser;

public interface UserManager {
    //查询，不需要事务控制
    public boolean checkUser(String name, String password) throws SQLException;

    //新增一个用户，需要事务控制，默认级别
    @Transaction
    public boolean addUser(AdminUser user) throws SQLException;

}

要把addUser改成其他事务隔离级别（比如oracle的serializable级别），稍微修改下：@Transaction(level=Connection.TRANSACTION_SERIALIZABLE)
public boolean addUser(AdminUser user) throws SQLException;

不准备详细解释例子的业务流程，不过是登录和增加用户两个业务方法，看下就明白。阅读本文前最好已经读过开头提过的两篇文章。我相信代码是最好的解释：）

dennis 2007-02-06 12:24 发表评论

设计自己的MVC框架

dennis — Tue, 06 Feb 2007 03:54:00 GMT

摘要: 阅读全文

dennis 2007-02-06 11:54 发表评论

一个ServiceLocator模式的实现

dennis — Tue, 06 Feb 2007 03:49:00 GMT

摘要: 阅读全文

dennis 2007-02-06 11:49 发表评论

缓存filter及资源池模式

dennis — Tue, 06 Feb 2007 03:47:00 GMT

摘要: 《J2EE设计模式》学习笔记阅读全文

dennis 2007-02-06 11:47 发表评论

设计模式之事务处理

dennis — Tue, 06 Feb 2007 03:32:00 GMT

摘要: 事务处理是企业应用需要解决的最主要的问题之一。J2EE通过JTA提供了完整的事务管理能力，包括多个事务性资源的管理能力。但是大部分应用都是运行在单一的事务性资源之上（一个数据库），他们并不需要全局性的事务服务。本地事务服务已然足够(比如JDBC事务管理）。本文并不讨论应该采用何种事务处理方式，主要目的是讨论如何更为优雅地设计事务服务。仅以JDBC事务处理为例。涉及到的DAO，Factory... 阅读全文

dennis 2007-02-06 11:32 发表评论