定义：

封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。

角色职责：

• Visitor抽象访问者：

抽象类或者接口，声明访问者可以访问哪些元素，具体到程序中就是visit方法的参数定义哪些对象是可以被访问的。

• ConcreteVisitor具体访问者：

它影响访问者访问到一个类后该怎么干，要做什么事情。

• Element抽象元素：

接口或者抽象类，声明接受哪一类访问者访问，程序上是通过accept方法中的参数来定义的。

• ConcreteElement具体元素：

实现accept方法，通常是visitor.visit(this)，基本上都形成了一种模式了。

• ObjectStruture结构对象：

元素产生者，一般容纳在多个不同类、不同接口的容器，如List、Set、Map等，在项目中，一般很少抽象出这个角色。

通用源码：

/*** 访问者模式* 抽象访问者*/
public interface IVisitor {//可以访问哪个对象public void visit(ConcreteElement1 element1);public void visit(ConcreteElement2 element2);
}/*** 访问者模式* 具体访问者*/
public class Visitor implements IVisitor {//访问element1@Overridepublic void visit(ConcreteElement1 element1) {element1.doSomething();}//访问element2@Overridepublic void visit(ConcreteElement2 element2) {element2.doSomething();}
}/*** 访问者模式* 抽象元素*/
public abstract class Element {//定义业务逻辑public abstract void doSomething();//允许谁来访问public abstract  void accept(IVisitor visitor);
}/*** 访问者模式*具体元素*/
public class ConcreteElement1 extends Element{//具体业务逻辑@Overridepublic void doSomething() {}//允许具体哪个访问者访问@Overridepublic void accept(IVisitor visitor) {visitor.visit(this);}
}
/*** 访问者模式*具体元素*/
public class ConcreteElement2 extends Element{//具体业务逻辑@Overridepublic void doSomething() {}//允许具体哪个访问者访问@Overridepublic void accept(IVisitor visitor) {visitor.visit(this);}
}import java.util.Random;/*** 访问者模式* 结构对象：存储访问者*/
public class ObjectStruture {//对象模拟器public static Element createElement(){Random random = new Random();if(random.nextInt(100) >50){return  new ConcreteElement1();}else {return  new ConcreteElement2();}}
}/***  访问者模式*  场景类*/
public class Client {public static void main(String [] args){for (int i = 0; i <10 ; i++) {//获取元素类型Element element = ObjectStruture.createElement();//接受访问者访问element.accept(new Visitor());}}
}

总结：

• 符合单一职责原则

具体元素角色也就是Employee抽象类的两个子类负责数据的加载，而Visitor类则负责报表的展现，两个不同的职责非常明确地分离开来，各自演绎变化。

• 优秀的扩展性

由于职责分开，继续增加对数据的操作是非常快捷的，例如，现在要增加一份给大老板的报表，这份报表格式又有所不同，直接在Visitor中增加一个方法，传递数据后进行整理打印。

• 灵活性非常高 

涉及独立的场景交给访问这更方便

• 具体元素对访问者公布细节

访问者要访问一个类就必然要求这个类公布一些方法和数据，也就是说访问者关注了其他类的内部细节，这是迪米特法则所不建议的。

• 具体元素变更比较困难

具体元素角色的增加、删除、修改都是比较困难的，就上面那个例子，你想想，你要是想增加一个成员变量，如年龄age，Visitor就需要修改，如果Visitor是一个还好办，多个呢？业务逻辑再复杂点呢？

• 违背了依赖倒置转原则

访问者依赖的是具体元素，而不是抽象元素，这破坏了依赖倒置原则，特别是在面向对象的编程中，抛弃了对接口的依赖，而直接依赖实现类，扩展比较难。

摘自《设计模式之禅》