Chen Jian

Go to http://www.ibm.com/developerworks/library/j-jester/ 一句话概括：Jester changes the source code, recompiles it, and runs the test suite to see if anything breaks 今天试玩了一下，我觉得它功能很强大很有意义，但是可用性太差了！ 具体原因我以后再说！

这里的质量，指的是功能点的覆盖性。 Kent Beck说有两种基本方法：    1.写更多的测试代码，最大可能穷尽所有的输入组合    2.或者把代码写得尽量简单，代码简单了IF/ELSE就少了，需要的测试用例也就少了。 他还推荐了一个工具用于检测测试代码的覆盖性: Jester

   最近在项目中反复使用了Visitor模式，觉得它真的很奇妙。    很多人用Visitor模式可能都和我一样，初衷是为了遍历一棵树，但其实在“树遍历”市场上还有其它方案可以选择，这些方案可能还更简单。那为什么还要用Visitor模式？难道它的方案更优？如果更优，它的优点有更高的意义？    我的答案是： Visitor是高性能高价格的方案，而且它的优点是“Sepration of Concern”。因为这个优点，它不但可用于树遍历，还可在任何需要多态的场合，提供比“子类直接实现”更低的耦合。    1.Visitor 可用于树遍历，visitorFather(), visitorSon()什么的，这没什么可说的。    2.其实不用Visitor也可以实现树遍历，而且还更直观。让Father和Son都实现一个visitTree()方法，Father.visitTree()在visit自己之后再调用所有Son的visitTree()方法，这种方案更符合直觉，而且不需要引入新类，比Visitor模式更简单。我们不妨把这种方案称作 直觉模式。    3. 那为什么说Visitor更优？        a. 直觉模式的算法是死的，而Visitor模式的算法不是。虽然 Father.visitTree() 跟 Son.visitTree() 的实现可以不一样，但是算法是死的，只能先序遍历，并且不能跳过节点。Visitor类可以任意组合自己的visitXXX()方法和决定这些方法的调用顺序，想先序就先序，想广度优先就广度优选，想跳过节点就跳过节点。        b. 直觉模式不方便处理与各节点无关的操作，而Visitor模式可以。比如要在访问Father和访问Son之间打印N个空格，用直觉模式就不好做：这个倒底算Father的职责还是Son的职责？用Visitor模式就没有这个问题，因为Visitor本身是肮脏的，你尽可以往里面塞入各种操作。而且Visitor类还可以设定一些成员变量作为上下文，为树遍历提供必要的背景信息。        c. 最关键的一点，直觉模式只能有一种遍历操作，而Visitor模式可以有多种，并且它们可以互不干涉地同时运行。这是因为Father.visitTree()只能写一个，运行时只能执行这一个方法；而一套Visitor可以有多个Visitor子类，各个子类可以同时实例化，同时运行。        d. 把这个结论推而广之，可以发现任何多态的场合都可以用Visitor模式。要实现多态，一般是让各子类分别实现指定的抽象方法；但就像前面说的，这种方法只能写一个； 在直觉模式中，父类被多态掉了，而子类却是死的。而在Visitor模式中，由于我们可以在运行时动态选择，以致于子类也多态掉了!        e. 再深入一步，我们可以发现直觉模式只在实现某种特定契约时使用了多态，契约本身是固定的；而Visitor模式却对契约本身也进行了抽象。比如说在直觉模式中，大家可以有“买菜”这种契约，可以有“去银行”这种契约，契约的种类是具体的，虽然Father.买菜()和Son.买菜()时的还价方式不同；而在Visitor模式中，大家只有一种契约，即“做”，“做”本身是抽象的，直到我们创建“买菜Visitor”,“去银行Visitor”时，这个契约才被具体化。这就是更高层次的“Separation of Concern”，对不对？     4. 最后，说一下Visitor模式的高代价(如果你还有耐心继续看)         a.不直观，很古怪的一种思维方式。并且Visitor与Visitable要频繁互调，别人跟你的代码时会很费劲。         b.要新加一个Visitor接口和N个具体类，并且这个接口要定义对所有“被访问类”的访问方法，这很麻烦         c.虽然可以引入Context作为Visitor的成员变量，但这个Context只是全局的。如果要在访问Son时拿到Father的相关信息，用Visitor模式就远远不如直觉模式好用。我的做法是为每个visitor方法都引入一个subContext参数，把父结点的信息保存在里面，再调用子结点的visitor方法。这是一种弱类型的方案，使用时要小心

为什么不多改一些代码再测？这样效率不会更高吗？ 因为代码写多了再测，就会遗漏一些测试点。比如说测试一个“圆”，你只能在圆孤上选择测试点；而这个圆其实是由两个半圆组成的（就像今天的日偏食），你本来还应该分别测试这两个半圆的边！ 那我们的测试粒度倒底要小到什么地步？Kent Beck说，看感觉。他用一句很口语化的话来概括："Are the teeny-tiny steps feeling restrictive? Take bigger steps; Are you feeling a little unsure? Take Smaller steps".

1. This is not Triangulation public void testMultiplication(){ Assert.assertEquals(new Dollar(3).times(2),6 ); } public int times(int i) { return 6; } 2. This is Triangulation public void testMultiplication(){ Assert.assertEquals(new Dollar(3).times(2),6 ); Assert.assertEquals(new Dollar(4).times(3),12 ); } public int times(int i) { return amount * i; } 3.A Triangle? Yes //test Assert.assertEquals(new Dollar(3).times(2),6 ); //1 Assert.assertEquals(new Dollar(4).times(3),12 ); …

[TDD] Triangulation Read More »

SOA的好处有很多种，我绝不否认。但以我的阅历，能体会的只有以下几种。     1. SOA的优点即分布式计算的优点        a. 解决信息孤岛问题，最大限度地利用现存系统        b. 业务层的复用，重用更好，冗余更少        c. 可重用性强，那么添加新功能就快        d. 冗余少，那么可维护性就好，适应需求变化的能力也就强        e. 相比于传统的分布式系统，SOA还提倡采用标准化的互操作性接口，并主张采用更大的业务组件粒度，这是它最大的创新之处。   2.从程序员的角度看， SOA导致了分而治之的开发模式，提高了软件活动的敏捷性。由于一个系统被拆散成多个相对独立的子系统，开发/测试/部署/项目管理/组织管理 的对象都变小很多，应付起来也更容易。比如说，以前开发时要打一个巨大的EAR包，部署一次要10分钟，现在拆散了，1分钟就可以部好了。

先记下来，以后再研究   1.SLA, Sevice Level Agreement   2.Java Business Integration (JBI)   3.EIP, Enterprise Integeration Patterns

打印 object.getClass().getResource(" /com/…/thisclassname.class").toString()  即可 如：jar:file:/H:/website/WEB-INF/lib/saaj-impl-1.3.2.jar!/com/sun/xml/messaging/saaj/soap/ver1_1/