设计模式（24）：访问者模式VISITOR

访问者模式

意图

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

---

使用场景

在下列情况下使用Visitor模式：

• 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。
• 需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor使得你可以将相关的操作集中起来定义在一个类中。当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。
• 定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

---

结构

访问者模式结构如下

• Visitor
  
  – 为该对象结构中ConcreteElement的每一个类声明一个Visit操作。该操作的方法名和参数标识了发送Visit请求给该Visitor的那个类。这使得Visitor可以确定正被访问元素的具体的类。这样Visitor就可以通过该元素的特定接口直接访问它。

• ConcreteVisitor
  
  – 实现每个由Visitor声明的操作。每一个操作实现了Structure对象中相关的类所定义的算法的一部分。ConcreteVisitor为该算法提供了上下文并存储它的局部状态。这一状态常常在遍历该结构的过程中累积结果。

• Element
  
  – 定义一个Accept操作，它以一个访问者为参数。

• ConcreteElement
  
  – 实现Accept操作，该操作以一个访问者为参数。

• ObjectStructure
  
  – 能枚举它的元素。
  
  – 可以提供一个高层的接口以允许该访问者访问它的元素。
  
  – 可以是一个Composite模式或是一个集合，如一个列表或一个无序集合。

协作

• 一个使用Visitor模式的Client必须创建一个ConcreteVisitor对象，然后遍历该对象结构，并用该访问者访问每一个元素。
• 当一个元素被访问时，它调用对应于它的类的Visitor操作。如果必要，该元素将自身作为这个操作的一个参数以便该访问者访问它的状态。

---

效果

• 访问者模式使得易于增加新的操作
  
  – 访问者使得增加依赖于复杂对象结构的构件的操作变得容易了。仅需增加一个新的Visitor即可在一个对象结构上定义一个新的操作。相反，如果每个功能都分散在多个类之上的话，定义新的操作时必须修改每一类。

• 访问者集中相关的操作而分离无关的操作
  
  – 相关的行为不是分布在定义该对象结构的各个类上，而是集中在一个Visitor中。无关行为却被分别放在它们各自的Visitor子类中。这就既简化了这些元素的类，也简化了在这些访问者中定义的算法。所有与它的算法相关的数据结构都可以被隐藏在访问者中。

• 增加新的ConcreteElement类很困难
  
  – Visitor模式使得难以增加新的Element的子类。每添加一个新的ConcreteElement都要在Visitor中添加一个新的抽象操作，并在每一个ConcreteElement类中实现相应的操作。有时可以在Visitor中提供一个缺省的实现，这一实现可以被大多数的ConcreteVisitor继承，但这与其说是一个规律还不如说是一种例外。所以在应用访问者模式时考虑关键的问题是系统的哪个部分会经常变化，是作用于对象结构上的算法呢还是构成该结构的各个对象的类。如果老是有新的ConcreteElement类加入进来的话，Visitor类层次将变得难以维护。在这种情况下，直接在构成该结构的类中定义这些操作可能更容易一些。如果Element类层次是稳定的，而你不断地增加操作获修改算法，访问者模式可以帮助你管理这些改动。

• 通过类层次进行访问
  
  – 一个迭代器可以通过调用节点对象的特定操作来遍历整个对象结构，同时访问这些对象。但是迭代器不能对具有不同元素类型的对象结构进行操作，而Visitor可以对不同类型对象进行操作。

• 累积状态
  
  – 当访问者访问对象结构中的每一个元素时，它可能会累积状态。如果没有访问者，这一状态将作为额外的参数传递给进行遍历的操作，或者定义为全局变量。

• 破坏封装
  
  – 访问者方法假定ConcreteElement接口的功能足够强，足以让访问者进行它们的工作。结果是，该模式常常迫使你提供访问元素内部状态的公共操作，这可能会破坏它的封装性。

访问者模式实现(Implement)

案例

“There are a thousand Hamlets in a thousand people’s eyes. ”一千个人心中有一千个哈姆雷特。现在用访问者模式来表达，假如《哈姆雷特》是一个类，对哈姆雷特的评价是其中的一个操作。

代码实现

莎士比亚的悲剧，对应模式中的Element

/* 莎士比亚的悲剧, Element in Pattern */
public abstract class TragedyOfShakespeare {
    public abstract void accept(TragedyVisitor tragedyVisitor);
}

《哈姆雷特》，对应模式中的ConcreteElement

/* 《哈姆雷特》, ConcreteElement in Pattern */
public class Hamlet extends TragedyOfShakespeare {
    @Override
    public void accept(TragedyVisitor tragedyVisitor) {
        tragedyVisitor.judgeOfHamlet(this);
    }
}

剧本的读者，对应模式中的Visitor

/* 剧本读者，Visitor in Pattern */
public abstract class TragedyVisitor {
    public abstract void judgeOfHamlet(Hamlet hamlet);
}

这里只列举一个ConcreteVisitor

/* 剧本读者学生A, ConcreteVisitor in Pattern */
public class StudentA extends TragedyVisitor {
    @Override
    public void judgeOfHamlet(Hamlet hamlet) {
        System.out.println("学生A眼中的哈姆雷特...");
    }
}

Client调用

public class VisitorDemoTest {
    @Test
    public void differentPeopleReadHamletTest() {
        TragedyOfShakespeare hamlet = new Hamlet();

        //开始阅读
        System.out.println("-----学生A开始读《哈姆雷特》-----");
        hamlet.accept(new StudentA());
        System.out.println("-----学生B开始读《哈姆雷特》-----");
        hamlet.accept(new StudentB());
        System.out.println("-----老师A开始读《哈姆雷特》-----");
        hamlet.accept(new TeacherA());
        System.out.println("-----老师B开始读《哈姆雷特》-----");
        hamlet.accept(new TeacherB());
    }
}

运行结果

-----学生A开始读《哈姆雷特》-----
学生A眼中的哈姆雷特...
-----学生B开始读《哈姆雷特》-----
学生B眼中的哈姆雷特...
-----老师A开始读《哈姆雷特》-----
老师A眼中的哈姆雷特...
-----老师B开始读《哈姆雷特》-----
老师B眼中的哈姆雷特...

总结

访问者模式的优点和缺点非常明显，它将数据的操作与数据的结构进行分离，就如同效果一节里面讲的，符合开闭原则，具有良好的扩展性，但是这个容易扩展是有条件的，在增加新的visitor时容易扩展，但是在修改Element对象的结构时会使得整个系统需要大量的修改。

参考代码