本文从一个给定的实现了组合（composite）模式的例子开始，说明怎么在这个数据结构上实现业务逻辑代码。依次介绍了非面向对象的方式、在组合结构中加入方法、使用访问者（visitor）模式以及用改进后的访问者（visitor）模式来实现相同的业务逻辑代码，并且对于每种实现分别给出了优缺点。

　　读者定位于具有java程序开发和设计模式经验的开发人员。

　　读者通过本文可以学到如何在组合（composite）模式中实现各种不同的业务方法及其优缺点。

　　组合（composite）模式

　　组合模式是结构型模式中的一种。gof的《设计模式》一书中对使用组合模式的意图描述如下：将对象组合成树形结构以表示"部分-整体"的层次结构。composite使得用户对单个对象和组合对象的使用具有一致性。

　　组合模式应用广泛。根据gof中对组合模式的定义，composite模式一般由component接口、leaf类和composite类组成。现在需要对一个软件产品管理系统的实体建模：某公司开发了一系列软件集（softwareset），包含了多种品牌（brand）的软件产品，就象ibm提供了lotus、websphere等品牌。每个品牌下面又有各种产品（product），如ibm的lotus下面有domino server/client产品等。建模后的类图如下（代码可以参见随本文带的附件中，包com.test.entity下所有的源文件）：

　　如图所示：

　　（1）接口softwarecomponent就是对应于组合模式中的component接口，它定义了所有类共有接口的缺省行为

　　（2）abssoftwarecomposite类对应于composite类，并且是抽象类，所有可以包含子节点的类都扩展这个类。这个类的主要功能是用来存储子部件，实现了接口中的方法，部分可以重用的代码写在此类中

　　（3）softwareset类继承于abssoftwarecomposite类，对应于软件集，软件集下直接可以包含品牌（brand），也可以直接包含不属于任何品牌的产品（product）

　　（4）brand类继承于abssoftwarecomposite类，对应于品牌，包含了品牌名属性，并且用来存储product类的实例

　　（5）product类就是对应的leaf类，表示叶子节点，叶子节点没有子节点

　　用不同的方法实现业务逻辑

　　数据结构建立好之后，需要在这个数据结构上添加方法实现业务逻辑。比如现在的这个例子中，有这样的需求：给定一些用户选择好的产品，需要计算出这些选中后软件的总价格。下面开始介绍如何使用各种不同的方法来实现这个业务逻辑。

　　非面向对象的编程方式

　　这种方式下，编程思路最简单：遍历softwareset实例中的所有节点，如果遍历到的当前对象是product的话就累加，否则继续遍历下一层直到全部遍历完毕。代码片断如下：

　　这段代码的好处是实现业务逻辑的时候无需对前面已经定好的数据结构做改动，并且效率比较高；缺点是代码凌乱而且频繁使用了instanceof判断类型和强制类型转换，代码的可读性不强，如果层次多了代码就更加混乱。

　　面向对象的编程方式（将计算价格的方法加入数据结构中）

　　下面我们采用面向对象的方式，可以这么做：在接口softwarecomponent中加入一个方法，名叫gettotalprice，方法的声明如下：

　　由于类brand和softwareset都继承了abssoftwarecomposite，我们只需在类abssoftwarecomposite中实现该方法gettotalprice方法即可，如下：
　　在product类中实现如下：
　　在外面需要取得某个对象的总价格的时候只需这样写（在本文的例子com.test.business.softwaremanager中可以找到这段代码）：

　　现在把业务逻辑的实现都放在了数据结构中（组合模式的结构中），好处很明显，每个类只管理自己相关的业务代码的实现，跟前面举的面向过程方式的实现方式相比，没有了instanceof和强制类型转换。但是不好的地方是如果需要增加新的业务方法的话就很麻烦，必须在接口softwarecomponent中首先声明该方法，然后在各个子类中实现并且重新编译。

　　使用访问者模式

　　使用访问者模式就能解决上面提到的问题：如果要经常增加或者删除业务功能方法的话，需要频繁地对程序进行重新实现和编译。根据面向对象设计原则之一的srp（单一职责原则）原则，如果一个类承担了多于一个的职责，那么引起该类变化的原因就会有多个，就会导致脆弱的设计，在发生变化时，原有的设计可能会遭到意想不到的破坏。下面我们引入了一个叫做visitor的接口，该接口中定义了针对各个子类的访问方法，如下所示：

　　visitbrand方法是访问brand对象节点的时候用的，剩下的方法依次类推。并在接口softwarecomponent中增加一个方法：
　　在softwareset中实现接口中的accept方法，首先直接调用visitor接口中的visitsoftwareset方法，传入的参数是本身对象，然后递归调用子对象的accept方法：

 　　在brand中实现接口中的accept方法，首先直接调用visitor接口中的visitbrand方法，传入的参数是本身对象，然后递归调用子对象的accept方法：
 　　其实在上面的两个类的实现中可以将遍历子节点并调用其accept方法的代码写到父类abssoftwarecomposite中的某个方法中，然后直接调用父类中的这个方法即可。这里为了解释方便分别写在了两个子类中。
　　
　　在product中实现接口中的accept方法，直接调用visitor接口的visitproduct方法即可：

 　　下面需要实现visitor接口，类名是caculatetotalpricevisitor，实现了计算总价格的业务逻辑，实现代码如下所示：

 　　上面那段代码中，首先在类内定义一个总价格的属性，由于brand和softwareset都没有价格，因此在实现中，只需在visitproduct方法中累加totalprice即可。在外面如果需要计算总价格的话这样写（在本文的例子com.test.business.softwaremanager中可以找到这段代码）：

 　　下面是它的时序图：在类softwaremanager中的main方法中，调用软件集对象（data）的accept方法，并将生成的visitor对象传给它。accept方法开始递归调用各个子对象的accept方法。如果当前的对象是softwareset的实例，则调用visitor对象visitsoftwareset方法，在visitor对象中对该节点的数据进行一些处理，然后返回；依次类推，遍历到brand对象和product对象也与此类似。当前的逻辑是计算软件产品的总价格，因此当遍历到product对象的时候，取出产品的价格并且累加，最后当结构遍历完毕后，调用visitor对象的gettotalprice方法返回给定软件集对象的（data）的总的价格。如果需要加入一个新的计算逻辑，只实现visitor接口，并且将该类的实例传给data对象的accept方法就可以实现不同的逻辑方法了。

 点击小图看大图

　　我们可以看到通过访问者模式很好地解决了如何加入新的业务代码而无需重新改动、编译既有代码。但是该模式也不是没有缺点：如果在组合模式中结构加入新的子类的话会导致接口visitor也跟着改动，导致所有visitor的子类都需要实现新增的方法。因此这种访问者模式适合于结构不经常变动的情况。

　　改进访问者模式

　　前面我们说到了如何使用visitor模式及使用该模式后的优缺点，下面举具体的例子说明。假设现在客户提出了一个产品集（productset）的概念：随着公司软件版本的增多，需要将同一个版本的产品（product）都放到产品集（productset）中，而一个品牌包含有多个产品集。因为现在组合结构中增加了一个节点，所以在visitor接口中也必须随之增加一个叫做visitproductset的方法，并且会导致原有系统中所有已经实现了visitor接口的类都需要重新实现并编译。用java的反射机制可以解决这个问题。

　　使用java的method reflection机制实现访问者模式

　　首先我们需要改变一下visitor接口，接口名叫做reflectionvisitor，如下所示：

　　在现在的接口的方法里，能接受任意的对象（参数是object）。

　　下面实现接口reflectionvisitor，名叫reflectionvisitorimpl，代码如下所示：

 　　这段代码首先判断传入的对象是否是空指针，然后创建class数组和object数组，然后用getmethod方法取得方法名是"visit"、方法的参数是"对象softwarecomposite对应的类"的方法，最后调用该方法。调用该方法的时候可能会发生nosuchmethodexception异常，发生这个异常就表明它的子类或者当前类中没有与参数中传入相对应的visit方法。

　　下面再来写新版本visitor类，扩展刚写好的那个reflectionvisitorimpl类，名叫caculatetotalpricereflectionvisitor，如下所示：

 　　代码中声明了两个visit方法（因为在类reflectionvisitorimpl中，查找名为visit、参数与传进去的对象匹配的的方法），一个是给product的，另外一个是给softwareset的。在这里softwareset中并没有价格，只需当前的对象是类product的实例的时候将价格累加即可。如果在组合模式的结构中增加了新的类，只需要在reflectionvisitorimpl的扩展类中声明一个visit方法，该方法的参数是新增加的类，对于文中的例子，只需增加下面的一个方法：

 　　在组合结构的接口softwarecomponent中改一下accept方法，参数是修改后的visitor接口，如下所示：

　　public void accept(reflectionvisitor visitor);

　　由于在类softwareset、brand和productset中实现上面accept方法的代码都一样，因此把代码抽象到上层共有的抽象类abssoftwarecomposite中，如下所示：

 　　现在如果想在外面要调用的话，代码如下所示（在本文的例子com.test.business.softwaremanager中可以找到这段代码）：

 　　另外由于没有实现brand类的visit方法，在组合结构遍历到brand的节点的时候会抛出nosuchmethodexception异常，就是没有关于该节点方法的实现，在当前的程序中会打印出一句话：

　　you did not implement the visit method for class:class com.test.entity.brand

　　如果运行程序时发生了别的异常，请参见相应的java api文档。

　　在现在的改进后的访问者模式中，如果在组合的结构中新增或删除节点并不会对已经实现了的visitor产生任何影响；如果新增了业务方法，只需扩展类reflectionvisitorimpl就可以了。因此很好地解决了访问者模式的问题。

　　改进访问者模式实现与既有代码对接

　　到现在为止，改进后的访问者模式好像已经很好地解决了所有出现的问题，但是考虑到有下面的这种情况：现在需要写一个jsp的标签库（taglib），这个标签库还必须具有visitor的功能（就是需要有遍历节点的功能），可以将节点的内容根据需要打印到html页面中。由于标签本身需要继承相应的类（如tagsupport），如果继续使用上面提供的方法将无法实现，因为java不允许多重继承。不过我们可以将原有reflectionvisitorimpl的代码再改进一下以解决这种情况，新的visitor的实现类叫newreflectionvisitorimpl，代码如下所示。

 　　该类的实现与上面的实现差不多，多了一个构造函数，在该构造函数的参数中传入实现了visit方法的类，并且维护了指向该类的一个引用，另外最重要的地方是下面的两行代码：

　　本来的代码中从本身的类及其子类中查找visit方法，而现在是从维护的目标类中查找visit方法。

　　现在需要写tag类，这个类扩展了tagsupport类，如下所示（为说明的方便，随本文的例子提供了一个模拟的tagsupport类）：

 　　如果想测试上面写的那段代码，（在本文的例子com.test.business.softwaremanager中可以找到这段代码））如下所示：

　　可以看到通过java的反射机制很好地解决了多重继承的问题，使该访问者模式能够更好地应用于你的应用中。另外可以看到，那些visit方法所在的类已经不是实现了接口reflectionvisitor，可以说是访问者模式在java语言的支持下的一种特殊实现。

　　如果担心引入类反射机制后带来的效率问题，你可以将method对象通过某种方式缓冲起来，这样不会每次从传入的对象中找visit方法，可以部分地提高效率。

　　结论

　　在给定的组合模式的数据结构中，实现业务逻辑的方法非常多，文中试着介绍了几种实现业务逻辑的方法，并给出了相应的实现方式下的优缺点。读者可以综合考虑应用的需求来决定相应的实现方法。