本文节选自《设计模式就该这样学》
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 弹架构 』可获取更多技术干货！
评论