本文节选自《设计模式就该这样学》
1 应用访问者模式实现KPI考核的场景
每到年底，管理层就要开始评定员工一年的工作绩效，员工分为工程师和经理；管理层有CEO和CTO。那么CTO关注工程师的代码量、经理的新产品数量；CEO关注工程师的KPI、经理的KPI及新产品数量。
因为CEO和CTO对于不同的员工的关注点是不一样的，这就须要对不同的员工类型进行不同的解决。此时，访问者模式能够派上用场了，来看代码。
//员工基类public abstract class Employee { public String name; public int kpi;//员工KPI public Employee(String name) { this.name = name; kpi = new Random().nextInt(10); } //外围办法，承受访问者的拜访 public abstract void accept(IVisitor visitor);}Employee类定义了员工根本信息及一个accept()办法，accept()办法示意承受访问者的拜访，由具体的子类来实现。访问者是一个接口，传入不同的实现类，可拜访不同的数据。上面看工程师Engineer类的代码。
//工程师public class Engineer extends Employee { public Engineer(String name) { super(name); } @Override public void accept(IVisitor visitor) { visitor.visit(this); } //工程师一年的代码量 public int getCodeLines() { return new Random().nextInt(10 * 10000); }}经理Manager类的代码如下。
//经理public class Manager extends Employee { public Manager(String name) { super(name); } @Override public void accept(IVisitor visitor) { visitor.visit(this); } //一年做的新产品数量 public int getProducts() { return new Random().nextInt(10); }}工程师被考核的是代码量，经理被考核的是新产品数量，二者的职责不一样。也正是因为有这样的差异性，才使得拜访模式可能在这个场景下发挥作用。Employee、Engineer、Manager 3个类型相当于数据结构，这些类型绝对稳固，不会发生变化。
将这些员工增加到一个业务报表类中，公司高层能够通过该报表类的showReport()办法查看所有员工的业绩，代码如下。
//员工业务报表类public class BusinessReport { private List<Employee> employees = new LinkedList<Employee>(); public BusinessReport() { employees.add(new Manager("经理-A")); employees.add(new Engineer("工程师-A")); employees.add(new Engineer("工程师-B")); employees.add(new Engineer("工程师-C")); employees.add(new Manager("经理-B")); employees.add(new Engineer("工程师-D")); } /** * 为访问者展现报表 * @param visitor 公司高层，如CEO、CTO */ public void showReport(IVisitor visitor) { for (Employee employee : employees) { employee.accept(visitor); } }}上面来看访问者类型的定义，访问者申明了两个visit()办法，别离对工程师和经理拜访，代码如下。
public interface IVisitor { //拜访工程师类型 void visit(Engineer engineer); //拜访经理类型 void visit(Manager manager);}下面代码定义了一个IVisitor接口，该接口有两个visit()办法，参数别离是Engineer和Manager，也就是说对于Engineer和Manager的拜访会调用两个不同的办法，以此达到差异化解决的目标。这两个访问者具体的实现类为CEOVisitor类和CTOVisitor类。首先来看CEOVisitor类的代码。
//CEO访问者public class CEOVisitor implements IVisitor { public void visit(Engineer engineer) { System.out.println("工程师: " + engineer.name + ", KPI: " + engineer.kpi); } public void visit(Manager manager) { System.out.println("经理: " + manager.name + ", KPI: " + manager.kpi + ", 新产品数量: " + manager.getProducts()); }}在CEO的访问者中，CEO关注工程师的KPI、经理的KPI和新产品数量，通过两个visit()办法别离进行解决。如果不应用访问者模式，只通过一个visit()办法进行解决，则须要在这个visit()办法中进行判断，而后别离解决，代码如下。
public class ReportUtil { public void visit(Employee employee) { if (employee instanceof Manager) { Manager manager = (Manager) employee; System.out.println("经理: " + manager.name + ", KPI: " + manager.kpi + ", 新产品数量: " + manager.getProducts()); } else if (employee instanceof Engineer) { Engineer engineer = (Engineer) employee; System.out.println("工程师: " + engineer.name + ", KPI: " + engineer.kpi); } }}这就导致了if...else逻辑的嵌套及类型的强制转换，难以扩大和保护，当类型较多时，这个ReportUtil就会很简单。而应用访问者模式，通过同一个函数对不同的元素类型进行相应解决，使构造更加清晰、灵活性更高。而后增加一个CTO的访问者类CTOVisitor。
public class CTOVisitor implements IVisitor { public void visit(Engineer engineer) { System.out.println("工程师: " + engineer.name + ", 代码行数: " + engineer.getCodeLines()); } public void visit(Manager manager) { System.out.println("经理: " + manager.name + ", 产品数量: " + manager.getProducts()); }}重载的visit()办法会对元素进行不同的操作，而通过注入不同的访问者又能够替换掉访问者的具体实现，使得对元素的操作变得更灵便，可扩展性更高，同时，打消了类型转换、if...else等“俊俏”的代码。
客户端测试代码如下。
public static void main(String[] args) { //构建报表 BusinessReport report = new BusinessReport(); System.out.println("=========== CEO看报表 ==========="); report.showReport(new CEOVisitor()); System.out.println("=========== CTO看报表 ==========="); report.showReport(new CTOVisitor());}运行后果如下图所示。
在上述案例中，Employee表演了Element角色，Engineer和Manager都是 ConcreteElement，CEOVisitor和CTOVisitor都是具体的Visitor对象，BusinessReport就是ObjectStructure。
访问者模式最大的长处就是减少访问者非常容易，从代码中能够看到，如果要减少一个访问者，则只有新实现一个访问者接口的类，从而达到数据对象与数据操作相拆散的成果。如果不应用访问者模式，而又不想对不同的元素进行不同的操作，则必然须要应用if...else和类型转换，这使得代码难以降级保护。
咱们要依据具体情况来评估是否适宜应用访问者模式。例如，对象构造是否足够稳固，是否须要常常定义新的操作，应用访问者模式是否能优化代码，而不使代码变得更简单。
2 从动态分派到动静分派
变量被申明时的类型叫作变量的动态类型（Static Type），有些人又把动态类型叫作显著类型（Apparent Type）；而变量所援用的对象的实在类型又叫作变量的理论类型（Actual Type）。比方：
List list = null;list = new ArrayList();下面代码申明了一个变量list，它的动态类型（也叫作显著类型）是List，而它的理论类型是ArrayList。依据对象的类型对办法进行的抉择，就是分派（Dispatch）。分派又分为两种，即动态分派和动静分派。
2.1 动态分派
动态分派（Static Dispatch）就是依照变量的动态类型进行分派，从而确定办法的执行版本，动态分派在编译期就能够确定办法的版本。而动态分派最典型的利用就是办法重载，来看上面的代码。
public class Main { public void test(String string){ System.out.println("string"); } public void test(Integer integer){ System.out.println("integer"); } public static void main(String[] args) { String string = "1"; Integer integer = 1; Main main = new Main(); main.test(integer); main.test(string); }}在动态分派判断的时候，依据多个判断根据（即参数类型和个数）判断出办法的版本，这就是多分派的概念，因为咱们有一个以上的考量规范，所以Java是动态多分派的语言。
2.2 动静分派
对于动静分派，与动态分派相同，它不是在编译期确定的办法版本，而是在运行时能力确定的。而动静分派最典型的利用就是多态的个性。举个例子，来看上面的代码。
interface Person{ void test();}class Man implements Person{ public void test(){ System.out.println("男人"); }}class Woman implements Person{ public void test(){ System.out.println("女人"); }}public class Main { public static void main(String[] args) { Person man = new Man(); Person woman = new Woman(); man.test(); woman.test(); }}这段代码的输入后果为顺次打印男人和女人，然而这里的test()办法版本，无奈依据Man和Woman的动态类型判断，他们的动态类型都是Person接口，基本无从判断。
显然，产生这样的输入后果，就是因为test()办法的版本是在运行时判断的，这就是动静分派。
动静分派判断的办法是在运行时获取Man和Woman的理论援用类型，再确定办法的版本，而因为此时判断的根据只是理论援用类型，只有一个判断根据，所以这就是单分派的概念，这时考量规范只有一个，即变量的理论援用类型。相应地，这阐明Java是动静单分派的语言。
3 访问者模式中的伪动静分派
通过后面的剖析，咱们晓得Java是动态多分派、动静单分派的语言。Java底层不反对动静双分派。然而通过应用设计模式，也能够在Java里实现伪动静双分派。在访问者模式中应用的就是伪动静双分派。所谓动静双分派就是在运行时根据两个理论类型去判断一个办法的运行行为，而访问者模式实现的伎俩是进行两次动静单分派来达到这个成果。
还是回到后面的KPI考核业务场景中，BusinessReport类中的showReport()办法的代码如下。
public void showReport(IVisitor visitor) { for (Employee employee : employees) { employee.accept(visitor); }}这里根据Employee和IVisitor两个理论类型决定了showReport()办法的执行后果，从而决定了accept()办法的动作。
accept()办法的调用过程剖析如下。
（1）当调用accept()办法时，依据Employee的理论类型决定是调用Engineer还是Manager的accept()办法。
（2）这时accept()办法的版本曾经确定，如果是Engineer，则它的accept()办法调用上面这行代码。
public void accept(IVisitor visitor) { visitor.visit(this); } 此时的this是Engineer类型，因而对应的是IVisitor接口的visit(Engineer engineer)办法，此时须要再依据访问者的理论类型确定visit()办法的版本，如此一来，就实现了动静双分派的过程。
以上过程通过两次动静双分派，第一次对accept()办法进行动静分派，第二次对访问者的visit()办法进行动静分派，从而达到依据两个理论类型确定一个办法的行为的成果。
而本来的做法通常是传入一个接口，间接应用该接口的办法，此为动静单分派，就像策略模式一样。在这里，showReport()办法传入的访问者接口并不是间接调用本人的visit()办法，而是通过Employee的理论类型先动静分派一次，而后在分派后确定的办法版本里进行本人的动静分派。
注：这里确定accept(IVisitor visitor)办法是由动态分派决定的，所以这个并不在此次动静双分派的领域内，而且动态分派是在编译期实现的，所以accept(IVisitor visitor)办法的动态分派与访问者模式的动静双分派并没有任何关系。动静双分派说到底还是动静分派，是在运行时产生的，它与动态分派有着实质上的区别，不能够说一次动静分派加一次动态分派就是动静双分派，而且访问者模式的双分派自身也是另有所指。
而this的类型不是动静分派确定的，把它写在哪个类中，它的动态类型就是哪个类，这是在编译期就确定的，不确定的是它的理论类型，请小伙伴们也要辨别开来。
4 访问者模式在JDK源码中的利用
首先来看JDK的NIO模块下的FileVisitor接口，它提供了递归遍历文件树的反对。这个接口上的办法示意了遍历过程中的要害过程，容许在文件被拜访、目录将被拜访、目录已被拜访、产生谬误等过程中进行管制。换句话说，这个接口在文件被拜访前、拜访中和拜访后，以及产生谬误的时候都有相应的钩子程序进行解决。
调用FileVisitor中的办法，会返回拜访后果的FileVisitResult对象值，用于决定以后操作实现后接下来该如何解决。FileVisitResult的规范返回值寄存在FileVisitResult枚举类型中，代码如下。
public interface FileVisitor<T> { FileVisitResult preVisitDirectory(T dir, BasicFileAttributes attrs) throws IOException; FileVisitResult visitFile(T file, BasicFileAttributes attrs) throws IOException; FileVisitResult visitFileFailed(T file, IOException exc) throws IOException; FileVisitResult postVisitDirectory(T dir, IOException exc) throws IOException;}（1）FileVisitResult.CONTINUE：这个拜访后果示意以后的遍历过程将会持续。
（2）FileVisitResult.SKIP_SIBLINGS：这个拜访后果示意以后的遍历过程将会持续，然而要疏忽以后文件/目录的兄弟节点。
（3）FileVisitResult.SKIP_SUBTREE：这个拜访后果示意以后的遍历过程将会持续，然而要疏忽当前目录下的所有节点。
（4）FileVisitResult.TERMINATE：这个拜访后果示意以后的遍历过程将会进行。
通过访问者去遍历文件树会比拟不便，比方查找文件夹内合乎某个条件的文件或者某一天内所创立的文件，这个类中都提供了绝对应的办法。它的实现其实也非常简单，代码如下。
public class SimpleFileVisitor<T> implements FileVisitor<T> { protected SimpleFileVisitor() { } @Override public FileVisitResult preVisitDirectory(T dir, BasicFileAttributes attrs) throws IOException { Objects.requireNonNull(dir); Objects.requireNonNull(attrs); return FileVisitResult.CONTINUE; } @Override public FileVisitResult visitFile(T file, BasicFileAttributes attrs) throws IOException { Objects.requireNonNull(file); Objects.requireNonNull(attrs); return FileVisitResult.CONTINUE; } @Override public FileVisitResult visitFileFailed(T file, IOException exc) throws IOException { Objects.requireNonNull(file); throw exc; } @Override public FileVisitResult postVisitDirectory(T dir, IOException exc) throws IOException { Objects.requireNonNull(dir); if (exc != null) throw exc; return FileVisitResult.CONTINUE; }}5 访问者模式在Spring源码中的利用
再来看访问者模式在Spring中的利用，Spring IoC中有个BeanDefinitionVisitor类，其中有一个visitBeanDefinition()办法，源码如下。
public class BeanDefinitionVisitor { @Nullable private StringValueResolver valueResolver; public BeanDefinitionVisitor(StringValueResolver valueResolver) { Assert.notNull(valueResolver, "StringValueResolver must not be null"); this.valueResolver = valueResolver; } protected BeanDefinitionVisitor() { } public void visitBeanDefinition(BeanDefinition beanDefinition) { visitParentName(beanDefinition); visitBeanClassName(beanDefinition); visitFactoryBeanName(beanDefinition); visitFactoryMethodName(beanDefinition); visitScope(beanDefinition); if (beanDefinition.hasPropertyValues()) { visitPropertyValues(beanDefinition.getPropertyValues()); } if (beanDefinition.hasConstructorArgumentValues()) { ConstructorArgumentValues cas = beanDefinition.getConstructorArgumentValues(); visitIndexedArgumentValues(cas.getIndexedArgumentValues()); visitGenericArgumentValues(cas.getGenericArgumentValues()); } } ...}咱们看到，在visitBeanDefinition()办法中，拜访了其余数据，比方父类的名字、本人的类名、在IoC容器中的名称等各种信息。
关注微信公众号『 Tom弹架构 』回复“设计模式”可获取残缺源码。
【举荐】Tom弹架构：30个设计模式实在案例（附源码），挑战年薪60W不是梦
本文为“Tom弹架构”原创，转载请注明出处。技术在于分享，我分享我高兴！
如果本文对您有帮忙，欢送关注和点赞；如果您有任何倡议也可留言评论或私信，您的反对是我保持创作的能源。关注微信公众号『 Tom弹架构 』可获取更多技术干货！