访问者模式详解：从双分派原理到Java实战应用

访问者模式放在整个系列第30篇，正好卡在一个挺微妙的位置——前面29种模式已经把创建型、结构型和大部分行为型模式都过完了，剩下最难啃的几种里，Visitor绝对算一个。很多朋友学到这儿会卡壳，因为前面的模式多少都能在业务代码里立刻找到影子，但Visitor模式的第一反应往往是“我什么时候需要这玩意儿？”说实话，我当年第一次看完理论也觉得这模式有点绕，直到后来在真实项目里遇到一个“对象结构稳定但操作频繁扩展”的场景，才真正体会到它的价值。这篇就把访问者模式从原理到实战摊开讲清楚，希望帮你把这块硬骨头啃下来。

1. 访问者模式到底是什么：一个反直觉的设计思路

1.1 从“把操作塞进对象”到“把操作抽出来”

先得理解最核心的问题：访问者模式解决的是哪一类矛盾？

我们平时写面向对象代码，习惯性的思路是“数据和行为绑在一起”，也就是一个对象既要存数据，又要提供操作数据的方法。这个东西在大多数时候是对的，但有一种情况会让它变得很尴尬——当你在一个相对固定的数据结构上，要不断添加新的操作时。

举个例子，假设你有一个文件系统，里面有文本文件、图片文件、视频文件三类对象。现在要算总大小、要生成索引、要统计类型占比……每个新需求都意味着往每个文件类里加一个新方法。改三个类是小事，问题是如果这个文件类型体系是你依赖的框架给你定好的，你不能改它的源码，这时候怎么办？访问者模式就是专门解决这个问题的。

我先把结论放在前面，用一句话概括访问者模式的本质：**把“数据结构”和“作用于结构上的操作”分离，并且让新增操作不需要修改已有的数据类。**关键在于操作不写在对象自己身上，而是放到一个独立的“访问者”里。

1.2 双分派：这个模式最反直觉的那块基石

很多教程讲到访问者模式，直接丢出 Element、Visitor、ObjectStructure 三个角色，读者看完代码觉得能跑，但理解不透为什么要绕这么大一个圈子。要真正吃透它，必须弄懂“双分派（Double Dispatch）”这个概念。

一般来说，Java/C++这类语言的方法调用是单分派的：你调用 obj.method(arg)，具体执行哪个方法，由 obj 的实际类型决定一次，再由 arg 的编译时类型决定一次，注意这里参数是看编译时类型，不是运行时类型。这就造成一个麻烦：我明明有一个 accept(Visitor v) 方法，在 accept 里面调用 v.visit(this)，这个 this 在编译器看来是当前元素类型，所以会正确调到你重载的那个 visit(TextFile) 或 visit(ImageFile)。这相当于先根据元素类型分派了一次，再根据访问者类型分派了一次，两次分派叠加在一起，才能让“同一种操作作用于不同类型时执行不同的逻辑”。

打个不严谨但好记的比方：单分派像一个学生去问老师问题，只说“我这题不会”，老师不知道怎么针对性回答；双分派像学生先报名字（元素类型），再说问题，老师才能精准解答。访问者模式的核心机制就是通过 accept 方法把元素的真实类型作为一次隐式分派，从而让 visit 方法的重载能够生效。

1.3 访问者模式的四大角色

先整体认识一下参与者，后面代码里会逐一落到实现。

• Visitor（访问者接口）：为每种元素类型声明一个 visit 重载方法，比如 visit(TextFile f)、visit(ImageFile f)。
• ConcreteVisitor（具体访问者）：实现每个 visit 方法，写出针对每种元素的具体操作逻辑。
• Element（元素接口）：声明一个 accept(Visitor v) 方法，接收访问者作为参数。
• ConcreteElement（具体元素）：实现 accept，最典型的写法就是 v.visit(this)。
• ObjectStructure（对象结构）：管理元素集合，可以遍历集合，让每个元素调用 accept，也可以理解为“导演”，负责把访问者带到每个元素面前。

2. 手写Java实现：从零搭建一个文件统计系统

2.1 场景设定与需求拆解

不搞空的例子，直接上一个能运行的学生作业/期末大作业级别的场景：一个简单的文件系统，里面有 TextFile、ImageFile、VideoFile 三个类，都要实现一个公共接口 FileElement。

需求先给两个操作：第一个统计所有文件的总大小，第二个生成所有文件的信息报告。如果按照传统思路，直接在文件类上分别加 getSize() 和 generateReport() 就行了，但这样新增一个操作（比如统计类型占比、检测文件名合法性）就得改所有文件类。我们这里用访问者模式，让新增操作不再影响文件类本身。

整个代码项目结构很简单，就是五个类/接口：FileElement（元素接口）、三个文件类型（具体元素）、FileSizeVisitor（具体访问者一）、ReportVisitor（具体访问者二）、FileStructure（对象结构，管理元素列表并触发遍历）。

2.2 元素接口与具体元素实现

先定义元素接口，所有文件类型都要实现它：

java复制public interface FileElement {
    void accept(FileVisitor visitor);
}

这个 accept 方法唯一的目的，就是把自己“暴露”给访问者，让访问者根据 this 的运行时类型去选择对应的 visit 重载。注意看，是 visitor.visit(this)，而不是自己去写业务逻辑。

然后定义三个具体元素类，这里只保留最小字段：

java复制public class TextFile implements FileElement {
    private String name;
    private int size;        // 单位：KB
    private int lineCount;   // 文本文件特有属性

    public TextFile(String name, int size, int lineCount) {
        this.name = name;
        this.size = size;
        this.lineCount = lineCount;
    }

    public String getName() { return name; }
    public int getSize() { return size; }
    public int getLineCount() { return lineCount; }

    @Override
    public void accept(FileVisitor visitor) {
        visitor.visit(this);
    }
}

java复制public class ImageFile implements FileElement {
    private String name;
    private int size;
    private int width;
    private int height;

    public ImageFile(String name, int size, int width, int height) {
        this.name = name;
        this.size = size;
        this.width = width;
        this.height = height;
    }

    public String getName() { return name; }
    public int getSize() { return size; }
    public int getWidth() { return width; }
    public int getHeight() { return height; }

    @Override
    public void accept(FileVisitor visitor) {
        visitor.visit(this);
    }
}

VideoFile 结构完全一样，多一个 duration 字段，这里不贴完整代码了，照着样子写就行。三个类里最关键的一行都是 visitor.visit(this)，这一行就是双分派的第一次分派。我最初学的时候总觉得这行代码像在“偷懒”，实际上它是整个模式的发动机。

2.3 访问者接口与两个具体访问者

接着定义访问者接口，重点来了：每个元素类型对应一个 visit 重载。

java复制public interface FileVisitor {
    void visit(TextFile file);
    void visit(ImageFile file);
    void visit(VideoFile file);
}

这里有个初学者容易踩的坑：以为可以用一个 visit(FileElement file) 代替三个重载。千万别这么干，Java 的方法重载是编译期静态绑定，如果参数写成接口类型，在 accept 里调 visitor.visit(this) 时，编译器只看得见 this 的静态类型是 FileElement（因为我们只让元素实现了 FileElement），它会固定选择 visit(FileElement) 那个版本，三个类的差异就彻底丢失了。这恰恰是访问者模式为什么必须为一对一重载的原因——它就是靠这个重载来弥补 Java 不支持多分派的能力。

下面实现一个统计文件总大小的访问者：

java复制public class FileSizeVisitor implements FileVisitor {
    private int totalSize = 0;

    @Override
    public void visit(TextFile file) {
        totalSize += file.getSize();
        System.out.println("统计文本文件: " + file.getName() + ", 大小: " + file.getSize() + "KB");
    }

    @Override
    public void visit(ImageFile file) {
        totalSize += file.getSize();
        System.out.println("统计图片文件: " + file.getName() + ", 大小: " + file.getSize() + "KB");
    }

    @Override
    public void visit(VideoFile file) {
        totalSize += file.getSize();
        System.out.println("统计视频文件: " + file.getName() + ", 大小: " + file.getSize() + "KB");
    }

    public int getTotalSize() {
        return totalSize;
    }
}

再看一个生成信息报告的访问者：

java复制public class ReportVisitor implements FileVisitor {
    private StringBuilder sb = new StringBuilder();

    @Override
    public void visit(TextFile file) {
        sb.append("文本文件: ").append(file.getName())
          .append(", 行数: ").append(file.getLineCount())
          .append("\n");
    }

    @Override
    public void visit(ImageFile file) {
        sb.append("图片文件: ").append(file.getName())
          .append(", 分辨率: ").append(file.getWidth())
          .append("x").append(file.getHeight())
          .append("\n");
    }

    @Override
    public void visit(VideoFile file) {
        sb.append("视频文件: ").append(file.getName())
          .append(", 时长: ").append(file.getDuration())
          .append("秒\n");
    }

    public String getReport() {
        return sb.toString();
    }
}

注意这里有个很微妙的点：FileSizeVisitor 的 visit(TextFile) 和 visit(ImageFile) 虽然代码几乎一样（都是累加 size），但它俩必须分开写。因为访问者模式的价值之一就是“元素类型不同，操作可以完全不同”，这个灵活性是靠每个重载独立实现的。即使现在它们逻辑相同，后续要改成“文本文件按实际大小、图片按两倍大小算”——它们有各自的扩展点。

2.4 对象结构与管理遍历

对象结构负责存放元素集合，并且让访问者逐个访问每个元素。最简单的情况下，它可以只是一个 List，加一个遍历方法：

java复制import java.util.ArrayList;
import java.util.List;

public class FileStructure {
    private List<FileElement> files = new ArrayList<>();

    public void addFile(FileElement file) {
        files.add(file);
    }

    public void accept(FileVisitor visitor) {
        for (FileElement file : files) {
            file.accept(visitor);
        }
    }
}

这个 accept 方法就是“导演”，遍历每个元素，元素自己决定怎么接待访问者。有人可能会问，遍历放在这里和放在客户端有什么区别？区别在于封装性：客户端只需要调用 structure.accept(visitor) 就完事，不需要自己写循环，也不需要知道集合内部的细节，这符合迪米特法则。

客户端测试类：

java复制public class Client {
    public static void main(String[] args) {
        FileStructure structure = new FileStructure();
        structure.addFile(new TextFile("readme.txt", 10, 52));
        structure.addFile(new ImageFile("avatar.png", 128, 800, 600));
        structure.addFile(new VideoFile("tutorial.mp4", 2048, 3600));

        FileSizeVisitor sizeVisitor = new FileSizeVisitor();
        structure.accept(sizeVisitor);
        System.out.println("总大小: " + sizeVisitor.getTotalSize() + "KB");

        System.out.println("====================");

        ReportVisitor reportVisitor = new ReportVisitor();
        structure.accept(reportVisitor);
        System.out.println(reportVisitor.getReport());
    }
}

运行结果一目了然：第一次遍历统计大小，第二次遍历生成报告，文件类代码一个字都没改。这就是访问者模式最核心的收益。

2.5 关键代码细节：为什么 accept 里必须是 visitor.visit(this)

我在上面提过这个点，但值得再展开一次，因为这是最容易理解偏的地方。用编译器视角去看：

在 TextFile.accept 里，this 的编译时类型是 TextFile，所以 visitor.visit(this) 在编译期就能确定调用的是 visit(TextFile) 这个重载。同理，ImageFile、VideoFile 各自绑定到自己的重载。所以 accept 方法不能别出心裁写成 visitor.visit((FileElement) this)，这一转换会让编译器认为 this 只是 FileElement 类型，于是所有元素都会调 visit(FileElement) 那个方法（如果有的话），三个类的差异直接在编译期就被抹掉了。

还有个小细节：accept 方法里是 visitor.visit(this) 而不是 visitor.visit(getName(), getSize()) 之类的传参形式。原因很简单，如果把属性拆开传，访问者得不到完整的对象引用，无法调用对象的其他方法，也没法做更复杂的状态管理。拿到完整对象引用，访问者可以在 visit 方法里检查对象内部状态、修改访问者自身的上下文，甚至触发对象的其他公开方法。

3. 双层架构的实战扩展：从简单Demo到可维护设计

https://img-blog.csdnimg.cn/direct/10aa25a6e25d45fd82dc371c2c6139b1.png

如果只是写一个小 Demo，上面代码已经够用了。但既然要做到期末大作业的程度，或者想在工作里真正落地，访问者模式还会牵扯更多东西。我挑几个特别值得讲透的点。

3.1 为什么要用接口而不是抽象类

用接口定义 FileElement 和 FileVisitor，好处是 Java 支持一个类实现多个接口，将来元素既要支持被访问者访问，又要挂在其他接口体系下，一点冲突都没有。而抽象类只能单继承，用了抽象类，元素类就不能继承别的基类了。这一点对本模式特别重要，因为一个元素很可能本身还属于别的业务类型体系。如果你用 Java 8+，还可以在访问者接口里写 default 方法，给某些 visit 重载提供默认实现，新的访问者不必实现所有重载，这在元素类型特别多的时候能减少大量空方法。

3.2 对象结构的高级玩法：树形结构与递归遍历

很多教程里的对象结构只演示线性 List，但真实项目里元素往往形成树形结构，比如文件目录。访问者模式在树形结构上有一个非常自然且优雅的做法：在目录节点的 accept 方法里，除了让访问者访问自己，还可以顺便触发其对子节点的遍历。

java复制public class DirectoryElement implements FileElement {
    private String name;
    private List<FileElement> children = new ArrayList<>();

    public DirectoryElement(String name) {
        this.name = name;
    }

    public void add(FileElement child) {
        children.add(child);
    }

    @Override
    public void accept(FileVisitor visitor) {
        // 先访问目录本身
        visitor.visit(this);
        // 再递归访问所有子元素
        for (FileElement child : children) {
            child.accept(visitor);
        }
    }
}

这么做的好处是遍历逻辑也收敛到元素自己身上了。你不需要在 FileStructure 里写递归，也不需要一个额外的数据结构来判断“这里该遍历到多深”，只要每个节点都知道怎么把自己往下传递就行。这就是“把行为还给对象”的另一种体现，不过这次是把遍历行为还给元素，而具体的操作逻辑还是在访问者里。

3.3 访问者的状态管理：单次遍历、多次复用

访问者对象本身可以携带状态，这是访问者模式比较隐晦但极其有用的能力。比如 FileSizeVisitor 里的 totalSize 字段，就是访问者的内部状态。使用时有两点要小心：

第一，同一个访问者实例如果被二次遍历，要不要清空状态？这取决于语义。如果 totalSize 想统计“某个目录的总大小”，两次遍历相加就不对了。所以我在实际代码里通常会加一个 reset 方法，或者每次新建访问者实例。说白了，访问者是有状态的，你得自己对生命周期负责。

第二，多个访问者可组合。如果两个访问者都实现了同样的接口，你可以在某个 CompositeVisitor 里持有两个内部访问者，把 visit 委托给它们。这样做的好处是，当你要对新文件类型添加新访问方法时，只需要修改 CompositeVisitor，对外暴露的还是单一访问者对象。

3.4 与迭代器模式的协同使用

访问者模式常和迭代器模式配合。对象结构里持有 List 或者 Set，对外用迭代器遍历，但迭代器只负责“到达每个元素”，到达之后调用 element.accept(visitor)，操作逻辑全在访问者里。两种模式的分工很明确：迭代器管“怎么走”，访问者管“到了之后做什么”。两个分开，任何一侧变化都不会互相影响。

我遇到有的项目里把遍历逻辑直接写在 FileStructure.accept 里，这没问题，但一旦元素从“列表”改成“树”或者“图”，accept 的实现就要跟着改。这时候把遍历抽成一个独立的 Iterator 实现类，反而更有弹性。不过也别为了模式而模式，元素集合简单时直接在 accept 里写个 for 循环就够了。

3.5 访问者模式的代价和维护成本

说到维护成本，我必须老老实实地把访问者的缺点也讲透。第一，它要求元素结构保持稳定。如果隔三差五往 FileElement 接口里加一个新元素类型，访问者接口就得多一个 visit 重载，所有具体访问者类都得同步实现这个新方法——这会让人非常烦躁。第二，它把一个本来内聚在对象里的操作，全部打散到访问者类里。如果访问者类只能访问元素类的公开方法，那没有问题；如果它需要访问元素的内部私有细节，就不得不暴露内部状态，破坏封装性。

这也是为什么很多架构师说访问者模式是“把简单问题复杂化”的模式。它适用于元素类型很稳定、操作多变的系统，而“又想类型多变、又想操作多变”的复杂系统，访问者模式会变成维护灾难。做期末大作业时，如果指导老师说“功能扩展方式不限”，你可以选访问者；但如果老师说“系统可能会加入新的文件类型”，一定慎用。

4. 适用场景、优缺点与相近模式对比

4.1 什么时候该用访问者模式：四个典型信号

先从正向角度来看，以下场景非常契合访问者模式：

• 对象结构非常稳定：元素类型的数量几乎不会变（比如 AST 语法树的节点类型、报表的固定列类型）。
• 操作频繁新增：业务上经常需要“在不改动现有类的情况下，增加新的处理逻辑”。
• 操作需要跨多种类型执行：例如编译器里对 AST 做类型检查、代码生成、优化，每个 pass 就是一个访问者。
• 元素类承担了太多职责：想把“非核心职责”比如序列化、校验、导出等，从元素类中剥离掉。

4.2 优缺点全景对比表

这张表的结论很直接：访问者模式是一把典型的高风险高收益的刀，用得好的地方是框架级的设计，用得不好的地方就变成过度设计。如果你是学生做设计模式大作业，强烈建议在“适用场景”那一节里把这张表写进去，评委会觉得你考虑得很周全。

4.3 与策略模式、迭代器模式的边界区分

初学者最容易把访问者模式和策略模式混起来。两者确实都像“把行为抽出来”，但观察的角度完全不同：

• 策略模式的侧重点是“同一个对象可以切换不同的算法”，比如排序时选择快排/归并/堆排，算法作用于同一个数据结构，数据结构不变，算法可以换。
• 访问者模式的侧重点是“同样的操作作用于不同类型对象集合”，数据结构有多个类型，操作种类也多个，要组合的是元素类型和操作类型两个维度。

迭代器模式和访问者模式的区别前面已经说了：迭代器管遍历，访问者管处理。记住这三个对照，写出来的分析会专业很多。

5. 实战中的优质代码结构：一份可直接改写的模板

只能跑通 Demo 并不会让大作业得高分，关键是代码结构要有清晰分区。下面给出一个可作为模板的课堂/作业项目结构，你可以直接复制去改业务场景：

code复制src/
├── element/
│   ├── FileElement.java          // 元素接口
│   ├── TextFile.java             // 具体元素A
│   ├── ImageFile.java            // 具体元素B
│   └── VideoFile.java            // 具体元素C
├── visitor/
│   ├── FileVisitor.java          // 访问者接口
│   ├── FileSizeVisitor.java      // 具体访问者A
│   └── ReportVisitor.java        // 具体访问者B
├── structure/
│   └── FileStructure.java        // 对象结构
└── client/
    └── Client.java               // 客户端测试

这样的分包方式从命名上就能看出职责边界。对一个设计模式大作业来说，代码结构甚至比算法实现更值钱。建议在注释里把“元素接口在什么情况下会变化”“访问者接口在什么情况下会变化”写清楚，这比堆 500 行注释都更能体现你的理解深度。

5.1 实战改造一：支持ZIP压缩导出操作

给文件系统加一个“压缩导出”功能：文本文件压缩成 .txt.zip，图片压缩成 .img.zip，视频压缩成 .vid.zip。只需要新写一个 ExportVisitor 实现 FileVisitor，三个重载方法分别输出不同的前缀，然后调用 structure.accept(exportVisitor) 即可。

这个场景生动体现了“不改元素类就新增操作”的价值。在真实项目里，元素类可能是第三方库或者别的团队维护的，你没法改它，但通过访问者模式却能给整套数据模型挂接额外能力。

5.2 实战改造二：文件类型自查与合法性校验

再写一个 ValidationVisitor：文本文件检查行数是否大于 0，图片分辨率是否为 8 的倍数（很多平台对上传图有这种约束），视频时长是否在合理范围内。三个重载方法各自做各的规则，互不干扰。这也是 Visitor 模式典型的“同一套对象，多个站不住脚的规则 checker”的场景。

这种“校验/分析/导出”类操作特别适合用访问者，因为它们是典型的一过性操作（一次性逻辑），没必要长驻在元素类身上。

5.3 实战改造三：在Android源码或其他开源框架中的应用

https://img-blog.csdnimg.cn/direct/18b84e90316f41ecbc1b2b2bd494d816.png

多说一句，很多人学设计模式会翻《Android源码设计模式解析与实战》，里面大量设计原则其实对应到源码实现时，访问者模式不算高频，但一旦用到就是核心场景。Java 的 javax.lang.model.element 包、Spring 的 BeanDefinitionVisitor、还有不少编译器前端像 Checkstyle、PMD、Lombok 注解处理器，都用到了访问者思想。看源码时打开脑洞，你会发现你写的这个文件统计小 Demo，和编译器做语法树遍历本质是同一个套路。

6. 常见问题与避坑技巧

6.1 坑一：重载方法没有被正确调用

这是最常见的 bug。症状是三个元素进去，访问者只调用了其中一个 visit 方法。原因多半是元素 accept 方法里把 this 类型写成了接口类型，或者访问者接口里只定义了一个 visit(FileElement) 方法。排查思路就是看 accept 里 visitor.visit(this) 的 this 的静态类型是否正确。

6.2 坑二：循环依赖和 null 元素处理

在 Java 里，Element 依赖 Visitor 接口，ConcreteVisitor 又依赖 ConcreteElement 来读取属性，这样就形成了两层间的环形依赖。在大型项目里，包依赖扫描可能会报警，需要通过模块化设计把接口和具体类分层解决。另一个常见麻烦是集合里有 null，遍历时调用 file.accept 会抛 NPE，建议在 addFile 时做非空校验，或者在 accept 遍历里主动判断。

6.3 坑三：把“是否使用访问者”当成炫技

这一点是过来人的最大体会：访客者模式在 90% 的业务 CRUD 中都毫无必要。如果只是偶尔增加操作，直接写一个工具类或者策略模式都更好。真正常见的使用场景集中在编译器、代码分析工具、报表引擎、UI 组件遍历这些领域。做期末大作业或者工作中选型时，一定先反思元素类型是否真的稳定。不要为了模式而模式，这是所有设计模式学习的通病。

6.4 期末大作业风格的测试用例怎么设计

如果你正卡在设计模式期末作业，可以按下面表设计测试用例，覆盖度高又加分：

这些用例也适合直接塞进你自己的测试代码里。既然作业要求控制台应用，最简单的验证方式就是在 main 方法里分场景运行并打印输出。

6.5 经验心得：学会用“视图”思维理解访问者

最后说一个我个人觉得特别有用的理解方式——把访问者模式想象成“给数据模型挂载视图”。你的元素类就是数据模型，非常稳定；访问者就是各种视图——列表视图、统计视图、导出视图、打印视图。数据模型不需要知道有多少种视图，视图却可以针对不同模型做精细处理。这个“数据-视图分离”的类比，帮我彻底弄懂了访问者模式，比单纯看 UML 类图直观得多。如果你也卡在理解上，建议就按这个思路想。

另外我还想补一句，读者里应该有正在做 Java 设计模式大作业的同学，不要只把 Demo 跑通就交差。试着给系统多写两个访问者，再写一段文字分析“如果新增元素类型，需要改动哪些类；如果新增访问者，需要改动哪些类”，这个对比分析往往就是拿高分的关键。毕竟访问者模式的精髓，恰恰就藏在这两个“改什么不改什么”的边界里。