1. 定义
访问者模式：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。
访问者模式
2. 使用场景
- 作为迭代器模式的扩充，业务规则要求遍历多个不同的对象，然后执行不同的操作，也就是针对访问的对象不同，执行不同的操作。这本身也是访问者模式出发点，迭代器模式只能访问同类或同接口的数据（避免使用instanceof）。
- 一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作，也就说是用迭代器模式已经不能胜任的情景。
- 需要对一个对象结构中的对象进行很多不同并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。
- 访问者模式可以充当拦截器（Interceptor）角色。
3. 实现
抽象元素以及具体元素：
/**
* 抽象元素
* 接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的
*/
public abstract class Element {
public String mCommonProperty;
public Element(String commonProperty) {
mCommonProperty = commonProperty;
}
public abstract void accept(Visitor visitor);
}
/**
* 具体元素
* 实现accept方法，通常是visitor.visit(this)，基本上都形成了一种模式了
*/
public class ConcreteElement1 extends Element {
public String mProperty1;
public ConcreteElement1(String commonProperty, String property) {
super(commonProperty);
this.mProperty1 = property;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
public class ConcreteElement2 extends Element {
public String mProperty2;
public ConcreteElement2(String commonProperty, String property) {
super(commonProperty);
this.mProperty2 = property;
}
@Override
public void accept(Visitor visitor) {
visitor.visit(this);
}
}
抽象访问者以及具体访问者：
/**
* 抽象访问者
* 抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法的参数定义哪些对象是可以被访问的
*/
public interface Visitor {
void visit(ConcreteElement1 element);
void visit(ConcreteElement2 element);
}
/**
* 具体访问者
* 影响访问者访问到一个类后该怎么干，要做什么事情。
*/
public class ConcreteVisitor1 implements Visitor {
@Override
public void visit(ConcreteElement1 element) {
//注：这里的访问逻辑需要根据具体业务来定
//一般来说，不同访问者对同一种元素类型有不同的访问方式
System.out.println("ConcreteVisitor1：" + element.mCommonProperty);
}
@Override
public void visit(ConcreteElement2 element) {
System.out.println("ConcreteVisitor1：" + element.mCommonProperty);
}
}
public class ConcreteVisitor2 implements Visitor {
@Override
public void visit(ConcreteElement1 element) {
System.out.println("ConcreteVisitor2：" + element.mProperty1);
}
@Override
public void visit(ConcreteElement2 element) {
System.out.println("ConcreteVisitor2：" + element.mProperty2);
}
}
场景类：
public class Client {
public static void main(String[] args) {
//这里的List充当了UML中的ObjectStruture——结构对象，又叫元素产生者，一般容纳在多个不同类、不同接口的容器，如List、Set、Map等。
//在项目中，一般很少抽象出这个角色。
List<Element> elements = new ArrayList<>();
elements.add(new ConcreteElement1("A", "1"));
elements.add(new ConcreteElement1("B", "2"));
elements.add(new ConcreteElement2("C", "3"));
elements.add(new ConcreteElement2("D", "4"));
Visitor visitor1 = new ConcreteVisitor1();
Visitor visitor2 = new ConcreteVisitor2();
for (Element e : elements) {
e.accept(visitor1);
}
System.out.println("-----------");
for (Element e : elements) {
e.accept(visitor2);
}
}
}
运行结果：
ConcreteVisitor1：A
ConcreteVisitor1：B
ConcreteVisitor1：C
ConcreteVisitor1：D
-----------
ConcreteVisitor2：1
ConcreteVisitor2：2
ConcreteVisitor2：3
ConcreteVisitor2：4
4. 优点
- 符合单一职责原则。具体元素角色负责数据的加载，而Visitor类则负责报表的展现，两个不同的职责非常明确地分离开来，各自演绎变化。
- 优秀的扩展性。由于职责分开，直接在Visitor中增加一个方法可以扩展对数据的操作。
- 灵活性非常高。例如访问不同的元素类型，使用不同的系数、参数等。
5. 缺点
- 违反迪米特原则。具体元素对访问者公布细节。
- 具体元素变更比较困难。具体元素的变更可能涉及到访问者的变更。
- 违背了依赖倒置转原则。访问者依赖的是具体元素，而不是抽象元素。直接依赖实现类使得扩展比较难。
