JarEye
- 浏览: 12568 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
转：在组合（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 方法，可以部分地提高效率。
分享到：
发表评论
相关推荐
电力日负荷曲线预测程序和数据集（预测未来一天的负荷曲线）
勾正科技向新而生智赢未来-2024年H1中国家庭智能大屏行业发展白皮书83页.pdf
题目2.2（成绩分析问题）：设计并实现一个成绩分析系统，们能够实现录入、保存一个班级学生多门课程的成绩，并成绩进行分析等功能。
更多毕业设计https://cv2022.blog.csdn.net/article/details/124463185
系统选用B/S模式，后端应用springboot框架，前端应用vue框架， MySQL为后台数据库。 本系统基于java设计的各项功能，数据库服务器端采用了Mysql作为后台数据库，使Web与数据库紧密联系起来。 在设计过程中，充分保证了系统代码的良好可读性、实用性、易扩展性、通用性、便于后期维护、操作方便以及页面简洁等特点。
内容概要：本文主要介绍了鸿蒙原生应用开发过程中可能遇到的内存问题以及相应的解决方案。针对这些问题，华为提供的 DevEco Studio 包含了性能分析工具 DevEco Profiler，提供两种场景化的分析模板——Snapshot Insight 和 Allocation Insight，支持实时监控、ArkTS 和 Native 内存的深度分析。这使得开发者能够有效识别、定界定位并优化内存问题，大幅提升应用的稳定性和性能。此外，文章还介绍了 DevEco Studio 强大的模拟器功能，该模拟器能仿真各类设备及场景，包括GPS定位、导航和低电量管理，极大提高了开发效率和测试灵活性。最后，文中详细列出了常见的快捷键，并给出了保持 DevEco Studio 与 Android Studio 快捷键同步的方法。 适合人群：专注于鸿蒙生态系统内的应用开发的技术人员，特别是有一定经验的中级至高级程序员。 使用场景及目标：本文旨在帮助开发者更好地理解和掌握 DevEco Studio 的强大工具链，尤其是解决开发过程中经常遇见的内存管理和多设备兼容问题，目标是优化开发流程，减少调测时间，增强产品的质量和用户体验。 阅读建议：开发者可通过鸿蒙官方提供的资源链接下载最新版本的 DevEco Studio 并探索相关技术博客，以获得最新的技术和使用技巧。建议在实践中逐步熟悉各个功能模块，并积极利用性能分析工具和模拟器来解决现实中的问题。
我是谁
精美导航引导页HTML源码，自适应手机/电脑，无后台，上传网站根目录就能用，首页内容在index里面修改 可以双页切换，亲测可用，搭建简单，附带修改教程
hap手机软件包测试，测试使用
内容概要：本文档是一份针对自动化专业的《电子线路CAD训练》实习报告，详细介绍了通过使用Altium Designer冬春软件进行电子线路的原理图设计、元件库文件设计、PCB板设计及元件封装库设计的过程。文档首先概述了训练的目的和重要性，随后逐步讲解Altium Designer Winter的安装与配置，然后重点展示了具体元件的设计细节，如温度传感器、AD输入通道、四双向模拟开关等的实际应用。此外，还详细阐述了自动布线和手动布线的具体步骤与注意事项，最后通过对此次实习的回顾，强调了本次训练对于提升电路设计能力和后续学习的支持。 适用人群：本报告适用于正在学习自动化及相关专业的在校大学生或从事电气工程领域的工程师和技术人员。 使用场景及目标：旨在帮助读者深入了解电子线路CAD的基础理论知识及其实际应用场景，特别是在Altium Designer环境下的操作流程。目标在于强化学生或技术人员的专业技能，以便他们能够在未来的工作或研究中有更强的设计能力。同时，该报告也可作为相关课程的教学材料。 其他说明：附录部分提供了完整的电路原理图和详细的元器件列表，供读者进一步理解和参照练习。
“2019年金融网点分县统计数据”提供了中国县域金融机构布局的详细信息，覆盖国有大型商业银行、股份制商业银行、城市商业银行及农村商业银行的网点分布特征。截至2019年底，全国银行网点总量为197,719个，其中县域地区分布87,003个，占比44%；市区网点110,716个，占比56%。 从银行类型看，国有大型商业银行县域网点数量最多（46,481个），但分布不均，如交通银行县域网点仅占9.01%，而邮政储蓄银行县域覆盖率高达59%。股份制商业银行县域网点仅占10%，主要集中于华东地区（73%）。农村商业银行县域网点占比60%（34,525个），华北和华中地区占其总量的53%。 区域分布上，华中地区县域网点占比最高（57.66%），其次是华东（34%）和西南（46%）；华南地区县域网点最少，仅占7%。国有大行在华东地区县域网点占比32%，农村商业银行则集中在华北（32%）和华中（21%）。 该数据为研究金融资源城乡配置、普惠金融发展及区域经济差异提供了基础支撑。例如，国有大行2019年县域网点数量较前一年增加，反映其下沉服务趋势；而农村金融机构通过人缘地缘优势持续优化县域服务。数据格式包含分银行、分地区的统计表格，适用于量化分析金融网络覆盖与经济社会发展的关联性。
GFP-ATOMIC参数的含义
ollama国内源，bash使用
内容概要：本文详细介绍了一家电动汽车（EV）制造商面临的数据处理挑战以及为解决这些问题所采取的举措——将现有数据平台迁移到Snowflake云平台上。文中阐述了制造商目前遇到的问题，如查询速度慢、运营成本高、难以整合结构化及非结构化的数据来源，并提出了具体的改进方向和技术细节。为了帮助潜在技术人员更好地理解和准备相关技术测试，还提供了一个详细的步骤指南来构建数据管道。具体要求分为两大部分：一是在当前架构上进行操作演示，二是利用Snowflake完成未来状态架构搭建并做技术示范，同时提供了预期产出物列表、所需技能概述及观众构成等关键信息。 适用人群：对于想要深入理解数据仓库迁移流程及其技术实施的专业人士非常有价值，特别适合作为数据工程师、数据科学家和其他IT专业人士参与面试的技术评估资料。 使用场景及目标：旨在展示候选人在构建现代数据工程基础设施方面的技术和创新能力。此外还可以作为内部培训材料供团队成员提高技能，或者为计划类似转型项目的企业决策层提供借鉴参考，从而优化其自身的数据管理策略和架构规划。 其他说明：演示时间被安排为60分钟，其中包括用例讲解（5分钟）、架构讨论（10分钟
自动封装javaBean的工具类
更多毕业设计https://cv2022.blog.csdn.net/article/details/124463185
更多毕业设计https://cv2022.blog.csdn.net/article/details/124463185
wireshark log for ethercat io
TM1629A 驱动程序和数据手册.rar
系统选用B/S模式，后端应用springboot框架，前端应用vue框架， MySQL为后台数据库。 本系统基于java设计的各项功能，数据库服务器端采用了Mysql作为后台数据库，使Web与数据库紧密联系起来。 在设计过程中，充分保证了系统代码的良好可读性、实用性、易扩展性、通用性、便于后期维护、操作方便以及页面简洁等特点。