- 浏览: 12481 次
- 性别:
- 来自: 北京
文章分类
最新评论
转:在组合(Composite)模式中实现访问者(Visitor)模式
原文地址:https://www.ibm.com/developerworks/cn/java/j-jinfh/
组合(Composite)模式
组合模式是结构型模式中的一种。GOF 的《设计模式》一书中对使用组合模式的意图描述如下:将对象组合成树形结构以表示"部分 - 整体"的层次结构。Composite 使得用户对单个对象和组合对象的使用具有一致性。
组合模式应用广泛。根据 GOF 中对组合模式的定义,Composite 模式一般由 Component 接口、Leaf 类和 Composite 类组成。现在需要对一个软件产品管理系统的实体建模:某公司开发了一系列软件集(SoftwareSet),包含了多种品牌(Brand)的软件产品,就象 IBM 提供了 Lotus、WebsPhere 等品牌。每个品牌下面又有各种产品(Product),如 IBM 的 Lotus 下面有 Domino Server/Client 产品等。建模后的类图如下:
如图所示:
接口 SoftwareComponent 就是对应于组合模式中的 Component 接口,它定义了所有类共有接口的缺省行为
AbsSoftwareComposite 类对应于 Composite 类,并且是抽象类,所有可以包含子节点的类都扩展这个类。这个类的主要功能是用来存储子部件,实现了接口中的方法,部分可以重用的代码写在此类中
SoftwareSet 类继承于 AbsSoftwareComposite 类,对应于软件集,软件集下直接可以包含品牌(Brand),也可以直接包含不属于任何品牌的产品(Product)
Brand 类继承于 AbsSoftwareComposite 类,对应于品牌,包含了品牌名属性,并且用来存储 Product 类的实例
Product 类就是对应的 Leaf 类,表示叶子节点,叶子节点没有子节点
用不同的方法实现业务逻辑
数据结构建立好之后,需要在这个数据结构上添加方法实现业务逻辑。比如现在的这个例子中,有这样的需求:给定一些用户选择好的产品,需要计算出这些选中后软件的总价格。下面开始介绍如何使用各种不同的方法来实现这个业务逻辑。
非面向对象的编程方式
这种方式下,编程思路最简单:遍历 SoftwareSet 实例中的所有节点,如果遍历到的当前对象是 Product 的话就累加,否则继续遍历下一层直到全部遍历完毕。代码片断如下:
这段代码的好处是实现业务逻辑的时候无需对前面已经定好的数据结构做改动,并且效率比较高;缺点是代码凌乱而且频繁使用了 instanceof 判断类型和强制类型转换,代码的可读性不强,如果层次多了代码就更加混乱。
面向对象的编程方式(将计算价格的方法加入数据结构中)
下面我们采用面向对象的方式,可以这么做:在接口 SoftWareComponent 中加入一个方法,名叫 getTotalPrice,方法的声明如下:
由于类 Brand 和 SoftwareSet 都继承了 AbsSoftwareComposite,我们只需在类 AbsSoftwareComposite 中实现该方法 getTotalPrice 方法即可,如下:
在 Product 类中实现如下:
在外面需要取得某个对象的总价格的时候只需这样写:
现在把业务逻辑的实现都放在了数据结构中(组合模式的结构中),好处很明显,每个类只管理自己相关的业务代码的实现,跟前面举的面向过程方式的实现方式相比,没有了 instanceof 和强制类型转换。但是不好的地方是如果需要增加新的业务方法的话就很麻烦,必须在接口 SoftWareComponent 中首先声明该方法,然后在各个子类中实现并且重新编译。
使用访问者模式
使用访问者模式就能解决上面提到的问题:如果要经常增加或者删除业务功能方法的话,需要频繁地对程序进行重新实现和编译。根据面向对象设计原则之一的 SRP(单一职责原则)原则,如果一个类承担了多于一个的职责,那么引起该类变化的原因就会有多个,就会导致脆弱的设计,在发生变化时,原有的设计可能会遭到意想不到的破坏。下面我们引入了一个叫做 Visitor 的接口,该接口中定义了针对各个子类的访问方法,如下所示:
visitBrand 方法是访问 Brand 对象节点的时候用的,剩下的方法依次类推。并在接口 SoftwareComponent 中增加一个方法:
public void accept(Visitor visitor);
在 SoftwareSet 中实现接口中的 accept 方法,首先直接调用 Visitor 接口中的 visitSoftwareSet 方法,传入的参数是本身对象,然后递归调用子对象的 accept 方法:
在 Brand 中实现接口中的 accept 方法,首先直接调用 Visitor 接口中的 visitBrand 方法,传入的参数是本身对象,然后递归调用子对象的 accept 方法:
其实在上面的两个类的实现中可以将遍历子节点并调用其 accept 方法的代码写到父类 AbsSoftwareComposite 中的某个方法中,然后直接调用父类中的这个方法即可。这里为了解释方便分别写在了两个子类中。
在 Product 中实现接口中的 accept 方法,直接调用 Visitor 接口的 visitProduct 方法即可:
下面需要实现 Visitor 接口,类名是 CaculateTotalPriceVisitor,实现了计算总价格的业务逻辑,实现代码如下所示:
上面那段代码中,首先在类内定义一个总价格的属性,由于 Brand 和 SoftwareSet 都没有价格,因此在实现中,只需在 visitProduct 方法中累加 totalPrice 即可。在外面如果需要计算总价格的话这样写:
下面是它的时序图:在类 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 方法,该方法的参数是新增加的类,对于文中的例子,只需增加下面的一个方法:
public void visit(ProductSet productSet) {
// 实现的代码
}
在组合结构的接口 SoftwareComponent 中改一下 accept 方法,参数是修改后的 Visitor 接口,如下所示:
public void accept(ReflectionVisitor visitor);
由于在类 SoftwareSet、Brand 和 ProductSet 中实现上面 accept 方法的代码都一样,因此把代码抽象到上层共有的抽象类 AbsSoftwareComposite 中,如下所示:
现在如果想在外面要调用的话,代码如下所示:
另外由于没有实现 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 类,如下所示:
如果想测试上面写的那段代码,如下所示:
可以看到通过 Java 的反射机制很好地解决了多重继承的问题,使该访问者模式能够更好地应用于你的应用中。另外可以看到,那些 visit 方法所在的类已经不是实现了接口 ReflectionVisitor,可以说是访问者模式在 Java 语言的支持下的一种特殊实现。
如果担心引入类反射机制后带来的效率问题,你可以将 Method 对象通过某种方式缓冲起来,这样不会每次从传入的对象中找 visit 方法,可以部分地提高效率。
原文地址:https://www.ibm.com/developerworks/cn/java/j-jinfh/
组合(Composite)模式
组合模式是结构型模式中的一种。GOF 的《设计模式》一书中对使用组合模式的意图描述如下:将对象组合成树形结构以表示"部分 - 整体"的层次结构。Composite 使得用户对单个对象和组合对象的使用具有一致性。
组合模式应用广泛。根据 GOF 中对组合模式的定义,Composite 模式一般由 Component 接口、Leaf 类和 Composite 类组成。现在需要对一个软件产品管理系统的实体建模:某公司开发了一系列软件集(SoftwareSet),包含了多种品牌(Brand)的软件产品,就象 IBM 提供了 Lotus、WebsPhere 等品牌。每个品牌下面又有各种产品(Product),如 IBM 的 Lotus 下面有 Domino Server/Client 产品等。建模后的类图如下:
如图所示:
接口 SoftwareComponent 就是对应于组合模式中的 Component 接口,它定义了所有类共有接口的缺省行为
AbsSoftwareComposite 类对应于 Composite 类,并且是抽象类,所有可以包含子节点的类都扩展这个类。这个类的主要功能是用来存储子部件,实现了接口中的方法,部分可以重用的代码写在此类中
SoftwareSet 类继承于 AbsSoftwareComposite 类,对应于软件集,软件集下直接可以包含品牌(Brand),也可以直接包含不属于任何品牌的产品(Product)
Brand 类继承于 AbsSoftwareComposite 类,对应于品牌,包含了品牌名属性,并且用来存储 Product 类的实例
Product 类就是对应的 Leaf 类,表示叶子节点,叶子节点没有子节点
用不同的方法实现业务逻辑
数据结构建立好之后,需要在这个数据结构上添加方法实现业务逻辑。比如现在的这个例子中,有这样的需求:给定一些用户选择好的产品,需要计算出这些选中后软件的总价格。下面开始介绍如何使用各种不同的方法来实现这个业务逻辑。
非面向对象的编程方式
这种方式下,编程思路最简单:遍历 SoftwareSet 实例中的所有节点,如果遍历到的当前对象是 Product 的话就累加,否则继续遍历下一层直到全部遍历完毕。代码片断如下:
/** * 取得某个 SoftwareComponent 对象下面所有 Product 的价格 * @param brand * @return */ public double getTotalPrice(SoftwareComponent softwareComponent) { SoftwareComponent temp = softwareComponent; double totalPrice = 0; // 如果传入的实例是 SoftwareSet 的类型 if (temp instanceof SoftwareSet) { Iterator it = ((SoftwareSet) softwareComponent).getChilds() .iterator(); while (it.hasNext()) {// 遍历 temp = (SoftwareComponent) it.next(); // 如果子对象是 Product 类型的,直接累加 if (temp instanceof Product) { Product product = (Product) temp; totalPrice += product.getPrice(); } else if (temp instanceof Brand) { // 如果子对象是 Brand 类型的,则遍历 Brand 下面所有的产品并累加 Brand brand = (Brand) temp; totalPrice += getBrandPrice(brand); } } } else if (temp instanceof Brand) { // 如果传入的实例是 SoftwareSet 的类型,则遍历 Brand 下面所有的产品并累加 totalPrice += getBrandPrice((Brand) temp); } else if (temp instanceof Product) { // 如果子对象是 Product 类型的,直接返回价格 return ((Product) temp).getPrice(); } return totalPrice; } /** * 取得某个 Brand 对象下面所有 Product 的价格 * @param brand * @return */ private double getBrandPrice(Brand brand) { Iterator brandIt = brand.getChilds().iterator(); double totalPrice = 0; while (brandIt.hasNext()) { Product product = (Product) brandIt.next(); totalPrice += product.getPrice(); } return totalPrice; }
这段代码的好处是实现业务逻辑的时候无需对前面已经定好的数据结构做改动,并且效率比较高;缺点是代码凌乱而且频繁使用了 instanceof 判断类型和强制类型转换,代码的可读性不强,如果层次多了代码就更加混乱。
面向对象的编程方式(将计算价格的方法加入数据结构中)
下面我们采用面向对象的方式,可以这么做:在接口 SoftWareComponent 中加入一个方法,名叫 getTotalPrice,方法的声明如下:
/** * 返回该节点中所有子节点对象的价格之和 * @return */ public double getTotalPrice();
由于类 Brand 和 SoftwareSet 都继承了 AbsSoftwareComposite,我们只需在类 AbsSoftwareComposite 中实现该方法 getTotalPrice 方法即可,如下:
public double getTotalPrice() { Iterator it = childs.iterator(); double price = 0; while (it.hasNext()) { SoftwareComponent softwareComponent = (SoftwareComponent) it.next(); // 自动递归调用各个对象的 getTotalPrice 方法并累加 price += softwareComponent.getTotalPrice(); } return price; }
在 Product 类中实现如下:
public double getTotalPrice(){ return price; }
在外面需要取得某个对象的总价格的时候只需这样写:
// getMockData() 方法返回数据 SoftwareComponent data = getMockData(); // 只需直接调用 data 对象的 getTotalPrice 方法就可以返回该对象下所有 product 对象的价格 double price = data. getTotalPrice(); // 找到某个对象后直接调用其 getTotalPrice 方法也可以返回总价格 price = data. findSoftwareComponentByID("id").getTotalPrice();
现在把业务逻辑的实现都放在了数据结构中(组合模式的结构中),好处很明显,每个类只管理自己相关的业务代码的实现,跟前面举的面向过程方式的实现方式相比,没有了 instanceof 和强制类型转换。但是不好的地方是如果需要增加新的业务方法的话就很麻烦,必须在接口 SoftWareComponent 中首先声明该方法,然后在各个子类中实现并且重新编译。
使用访问者模式
使用访问者模式就能解决上面提到的问题:如果要经常增加或者删除业务功能方法的话,需要频繁地对程序进行重新实现和编译。根据面向对象设计原则之一的 SRP(单一职责原则)原则,如果一个类承担了多于一个的职责,那么引起该类变化的原因就会有多个,就会导致脆弱的设计,在发生变化时,原有的设计可能会遭到意想不到的破坏。下面我们引入了一个叫做 Visitor 的接口,该接口中定义了针对各个子类的访问方法,如下所示:
public interface Visitor { public void visitBrand(Brand brand); public void visitSoftwareSet(SoftwareSet softwareSet); public void visitProduct(Product product); }
visitBrand 方法是访问 Brand 对象节点的时候用的,剩下的方法依次类推。并在接口 SoftwareComponent 中增加一个方法:
public void accept(Visitor visitor);
在 SoftwareSet 中实现接口中的 accept 方法,首先直接调用 Visitor 接口中的 visitSoftwareSet 方法,传入的参数是本身对象,然后递归调用子对象的 accept 方法:
public void accept(Visitor visitor) { visitor.visitSoftwareSet(this); Iterator it = childs.iterator(); while (it.hasNext()) { SoftwareComponent component = (SoftwareComponent)it.next(); component.accept(visitor); } }
在 Brand 中实现接口中的 accept 方法,首先直接调用 Visitor 接口中的 visitBrand 方法,传入的参数是本身对象,然后递归调用子对象的 accept 方法:
public void accept(Visitor visitor) { visitor.visitBrand(this); Iterator it = childs.iterator(); while (it.hasNext()) { SoftwareComponent component = (SoftwareComponent)it.next(); component.accept(visitor); } }
其实在上面的两个类的实现中可以将遍历子节点并调用其 accept 方法的代码写到父类 AbsSoftwareComposite 中的某个方法中,然后直接调用父类中的这个方法即可。这里为了解释方便分别写在了两个子类中。
在 Product 中实现接口中的 accept 方法,直接调用 Visitor 接口的 visitProduct 方法即可:
public void accept(Visitor visitor) { visitor.visitProduct(this); }
下面需要实现 Visitor 接口,类名是 CaculateTotalPriceVisitor,实现了计算总价格的业务逻辑,实现代码如下所示:
public class CaculateTotalPriceVisitor implements Visitor { private double totalPrice; public void visitBrand(Brand brand) { } public void visitSoftwareSet(SoftwareSet softwareSet) { } public void visitProduct(Product product) { // 每次在组合的结构中碰到 Product 对象节点的时候,就会调用此方法 totalPrice += product.getPrice(); } public double getTotalPrice() { return totalPrice; } }
上面那段代码中,首先在类内定义一个总价格的属性,由于 Brand 和 SoftwareSet 都没有价格,因此在实现中,只需在 visitProduct 方法中累加 totalPrice 即可。在外面如果需要计算总价格的话这样写:
// 建立一个新的 Visitor 对象 CaculateTotalPriceVisitor visitor = new CaculateTotalPriceVisitor(); // 将该 visitor 对象传到结构中 data.accept(visitor); // 调用 visitor 对象的 getTotalPrice() 方法就返回了总价格 double price = visitor.getTotalPrice();
下面是它的时序图:在类 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,如下所示:
public interface ReflectionVisitor { /** * 定义了一个访问节点的方法 * @param softwareComposite */ public void visitSoftwareComposite(Object softwareComposite); }
在现在的接口的方法里,能接受任意的对象(参数是 Object)。
下面实现接口 ReflectionVisitor,名叫 ReflectionVisitorImpl,代码如下所示:
public class ReflectionVisitorImpl implements ReflectionVisitor { public void visitSoftwareComposite(Object softwareComposite) { // 判断是否是 null if (softwareComposite == null) { throw new NullPointerException("The visit node should not be null!"); } // 组装 class 数组,即调用动态方法的时候参数的类型 Class[] classes = new Class[] { softwareComposite.getClass() }; // 组装与 class 数组相对应的值 Object[] objects = new Object[] { softwareComposite }; try { // 查找 visit 方法 Method m = getClass().getMethod("visit", classes); // 调用该方法 m.invoke(this, objects); } catch (NoSuchMethodException e) { // 没有找到相应的方法 System.out .println("You did not implement the visit method for class:" + softwareComposite.getClass()); } catch (Exception e) { // 发生了别的异常 System.out.println("Catched excepction in visit method."); e.printStackTrace(); } } }
这段代码首先判断传入的对象是否是空指针,然后创建 class 数组和 object 数组,然后用 getMethod 方法取得方法名是"visit"、方法的参数是"对象 softwareComposite 对应的类"的方法,最后调用该方法。调用该方法的时候可能会发生 NoSuchMethodException 异常,发生这个异常就表明它的子类或者当前类中没有与参数中传入相对应的 visit 方法。
下面再来写新版本 Visitor 类,扩展刚写好的那个 ReflectionVisitorImpl 类,名叫 CaculateTotalPriceReflectionVisitor,如下所示:
public class CaculateTotalPriceReflectionVisitor extends ReflectionVisitorImpl { private double totalPrice; public void visit(Product product) { totalPrice += product.getPrice(); } public void visit(SoftwareSet softwareSet) { System.out.println("No price for software set."); } public double getTotalPrice() { return totalPrice; } }
代码中声明了两个 visit 方法(因为在类 ReflectionVisitorImpl 中,查找名为 visit、参数与传进去的对象匹配的的方法),一个是给 Product 的,另外一个是给 SoftwareSet 的。在这里 SoftwareSet 中并没有价格,只需当前的对象是类 Product 的实例的时候将价格累加即可。如果在组合模式的结构中增加了新的类,只需要在 ReflectionVisitorImpl 的扩展类中声明一个 visit 方法,该方法的参数是新增加的类,对于文中的例子,只需增加下面的一个方法:
public void visit(ProductSet productSet) {
// 实现的代码
}
在组合结构的接口 SoftwareComponent 中改一下 accept 方法,参数是修改后的 Visitor 接口,如下所示:
public void accept(ReflectionVisitor visitor);
由于在类 SoftwareSet、Brand 和 ProductSet 中实现上面 accept 方法的代码都一样,因此把代码抽象到上层共有的抽象类 AbsSoftwareComposite 中,如下所示:
public void accept(ReflectionVisitor visitor) { visitor.visitSoftwareComposite(this); Iterator it = childs.iterator(); while (it.hasNext()) { SoftwareComponent component = (SoftwareComponent) it.next(); // 递归调用子对象的 accept 方法 component.accept(visitor); } }
现在如果想在外面要调用的话,代码如下所示:
// 建立一个新的 Visitor 对象 CaculateTotalPriceReflectionVisitor reflectionVisitor = new CaculateTotalPriceReflectionVisitor(); // 将该 visitor 对象传到结构中 data.accept(reflectionVisitor); // 调用 visitor 对象的 getTotalPrice() 方法就返回了总价格 double price = reflectionVisitor.getTotalPrice();
另外由于没有实现 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,代码如下所示。
public class NewReflectionVisitorImpl implements ReflectionVisitor { // 实现 visit 方法的类 private Object targetObject; // 构造方法,传入实现了 visit 方法的类 public NewReflectionVisitorImpl(Object targetObject) { if (targetObject == null) throw new NullPointerException( "The target object should not be null!"); this.targetObject = targetObject; } public void visitSoftwareComposite(Object softwareComposite) { // ……与上个例子相同 try { // 从目标的对象中查找 visit 方法 Method m = targetObject.getClass().getMethod("visit", classes); // 调用该方法 m.invoke(targetObject, objects); } catch (NoSuchMethodException e) { // ……与上个例子相同 } catch (Exception e) { // ……与上个例子相同 } } }
该类的实现与上面的实现差不多,多了一个构造函数,在该构造函数的参数中传入实现了 visit 方法的类,并且维护了指向该类的一个引用,另外最重要的地方是下面的两行代码:
// 从目标的对象中查找 visit 方法 Method m = targetObject.getClass().getMethod("visit", classes); // 调用该方法 m.invoke(targetObject, objects);
本来的代码中从本身的类及其子类中查找 visit 方法,而现在是从维护的目标类中查找 visit 方法。
现在需要写 Tag 类,这个类扩展了 TagSupport 类,如下所示:
public class MyTag extends TagSupport { SoftwareComponent softwareComponent = null; private double totalPrice = 0; public int doEngTag() { // 创建一个 visitor 对象,并且将本身传入 visitor 对象中 ReflectionVisitor visitor = new NewReflectionVisitorImpl(this); // 遍历结构 softwareComponent.accept(visitor); // 打印出价格 out.println(totalPrice); return 1; } // 实现了针对 Product 的 visit 方法 public void visit(Product product) { totalPrice += product.getPrice(); } public void visit(Brand brand) { out.println(brand.getId() + brand.getDescription()); } // …… }
如果想测试上面写的那段代码,如下所示:
//getMockData() 方法返回数据 SoftwareComponent data = getMockData(); MyTag myTag = new MyTag(); myTag.setSoftwareComponent(data); // 计算总价格,并打印出来 myTag.doEngTag();
可以看到通过 Java 的反射机制很好地解决了多重继承的问题,使该访问者模式能够更好地应用于你的应用中。另外可以看到,那些 visit 方法所在的类已经不是实现了接口 ReflectionVisitor,可以说是访问者模式在 Java 语言的支持下的一种特殊实现。
如果担心引入类反射机制后带来的效率问题,你可以将 Method 对象通过某种方式缓冲起来,这样不会每次从传入的对象中找 visit 方法,可以部分地提高效率。
相关推荐
《20101231行政区划代码》是一个数据资源,主要包含了2010年12月31日时中国各地的行政区域划分信息。这个数据集以Excel格式提供,具有高度的精确性,可以细化到村庄级别的行政单位。这种详细的数据对于研究、数据...
【标题】"长江养老CAS系统接口开发20101231"涉及的主要知识点是企业级应用中的身份验证和授权服务(Central Authentication Service,CAS)的系统接口开发。CAS是一种开源的单点登录(Single Sign-On,SSO)协议,...
《Mini6410 Android编程开发指南》是一本专门针对Mini6410和Tiny6410开发板的Android应用程序开发手册,由广州友善之臂计算机科技有限公司编撰。此手册适用于对嵌入式开发感兴趣的初学者,特别是那些希望在Mini6410...
说明: LIN协议v2.2A,包括协议规范包、物理层规范、应用程序接口规范、节点能力语言规范以及配置语言规范 (LIN protocol v2.2A, including the protocol specification package, the physical layer specification...
从国家统计局网站上下载,转换成excel版本,并用程序整理了一下,添加了id,pid,fullname 作者:rancococ
【输配电管理所工作总结】 这份2010年度的工作总结展示了输配电管理所在安全生产和维护工作方面的卓越成就。总结中提到了六个突出的成绩,涵盖了安全生产风险管理体系、带电作业、超高压线路运行、特重大保供电任务...
MyMPC解码包为一款轻量级的媒体解码器安装包,集成了目前主流的...# ffdshow_rev3710_20101231_alexins -> ffdshow_rev3740_20110116_alexins;# MPC-HC 播放器 v1.4 (Rev 2808) -> v1.4 (Rev 2862) 完整版,改进连续播
1. 塞班系统手机客户端安装:player_HB_3rd_20101231.sisx用于塞班3.0系统,player_HB_5th_20110107.sisx用于塞班5.0系统。 2. iPhone系统手机客户端安装:player用于iPhone(OS)系统手机,客户端需要手机通过网络...
- **OGRE依赖库**:`OgreDependencies_MSVC_20101231.zip` - **DirectX SDK**:`DXSDK_Aug09.exe` - **CMake**:`cmake-2.8.7-win32-x86.exe` - **Boost库**:`boost_1_48_0.zip` - **MyGUI图形用户界面库**:`MyGUI...
- 客户端设置简单,根据手机型号和操作系统选择对应的应用,如player_HB_3rd_20101231.sis、player_HB_5th_20110107.sisx等。 - iPhone需要通过网络下载HBplayer,其他系统通常在光盘中提供客户端。 5. 注意事项...
优化了量产后上盘的速度(包括升级后上盘速度), 可以在MW8109量产工具_20101231_SPI\releases\usr\etc 目录下修改INI是否打开\关闭提速功能 A、IsClusterEx为族大小控制 IsClusterEx=0时为4K,与原来一样 ...
2. “最新县及县以上行政区划代码整理版(20101231).xlsx”:这是Excel的XLSX格式文件,可能包含了一个整理过的行政区域代码表格,包括省、市、区的名称和对应的代码,便于数据分析和处理。 3. “最新县及县以上行政...
8. **报告日期**:报告中提及的“20101231”可能表示审计的是截至2010年12月31日的财务年度,而“2011”年可能是审计报告的出具年份。 9. **审计报告格式**:审计报告通常包括引言、管理层责任、审计师责任、审计...
《Citrix虚拟化解决方案交流20101231.ppt》可能是关于2010年12月31日的一次 Citrix 虚拟化解决方案的交流会议记录,其中可能包含了对XenServer在制造业应用案例的分析,展示了如何通过虚拟化提升生产效率和降低成本...
文件名"20101230、20110104、20101231"可能代表的是不同日期的代码版本或日志记录。在实际项目中,为了保持代码的整洁和版本管理,通常会采用如Git这样的版本控制系统来跟踪文件的变更历史。 总结,这个J2EE与AJAX...
6. **Subscriptionexpirationdate(YYYYMMDD)**: 20101231 - 这条信息指出了注册码的有效期限,即到期时间为2010年12月31日。 - 与之前提到的注册码只到2009年7月相比,这是一个显著的延长。 7. **...
"20101231ʲ2010"可能表示审计报告涵盖的时间段,即从2010年1月1日到2010年12月31日。 "�� �����Б��������"这部分可能是对审计报告中关键部分的概述,如收入、成本、利润等主要财务指标的详细分析...
标题“OgreDependencies_MSVC_20120819”揭示了这是一个与Ogre图形渲染引擎相关的项目,特别地,它包含了Ogre在Microsoft Visual Studio 2012环境下运行所需的依赖库。Ogre是一个开源的3D图形渲染引擎,广泛用于游戏...