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