## 01、痛点

我是老李。前阵子我接手了一个已经跑了几年的员工管理系统。系统里员工类型不多：工程师、产品经理、管理者，三种。最早只是为了算工资，每个员工类里写一个 computeSalary()，相安无事。后来业务要算绩效，于是每个类里面又加了一个 computePerformance()。再后来要做成本分析，又加 computeCost()。然后报表、人效、预算、培训支出……每个需求一进来，第一反应就是：Employee 的三个子类各改一遍。

问题不在工资算法复杂，而在于“员工类型是稳定的，统计操作是持续增加的”。但代码写反了：操作长在了类型身上。结果是：

- 每新增一个统计，就要改 Engineer、ProductManager、Manager 三个文件。
- 三类员工的统计代码互相拷贝，差异藏在一堆条件里，改一处漏两处。
- 统计逻辑散落在各个类里，薪资规则、绩效公式、成本口径混在一起。
- 一些带遍历的统计在 ObjectStructure 里写 instanceof 判断，越写越长。
- 新人看到 Employee 子类里十几个统计方法，完全不敢动。

早期代码通常长这样：

```java
public abstract class Employee {
    private String name;
    private double baseSalary;

    public abstract double computeSalary();
    public abstract double computePerformance();
    public abstract double computeCost();
    // 以后还会有 computeTrainingBudget()、computeReport() 等
}

public class Engineer extends Employee {
    @Override public double computeSalary() { return getBaseSalary() * 1.2; }
    @Override public double computePerformance() { return getBaseSalary() * 0.3; }
    @Override public double computeCost() { return getBaseSalary() * 1.8; }
}

public class ProductManager extends Employee {
    @Override public double computeSalary() { return getBaseSalary() * 1.3; }
    @Override public double computePerformance() { return getBaseSalary() * 0.4; }
    @Override public double computeCost() { return getBaseSalary() * 2.0; }
}

public class Manager extends Employee {
    @Override public double computeSalary() { return getBaseSalary() * 1.5; }
    @Override public double computePerformance() { return getBaseSalary() * 0.5; }
    @Override public double computeCost() { return getBaseSalary() * 2.5; }
}
```

统计入口更难看：

```java
public class EmployeeStatistics {
    public double totalSalary(List<Employee> employees) {
        double sum = 0;
        for (Employee e : employees) {
            if (e instanceof Engineer) {
                sum += e.computeSalary();
            } else if (e instanceof ProductManager) {
                sum += e.computeSalary();
            } else if (e instanceof Manager) {
                sum += e.computeSalary();
            }
        }
        return sum;
    }
}
```

设计模式真正解决的，不是“代码写得不高级”，而是“变化开始失控”。访问者模式正好就是针对“对象结构稳定、操作经常变化”这一种失控。

> 锐评：如果一个系统只有两类员工，而且未来三年只有工资计算，你硬塞进去 Visitor、Element、ObjectStructure，那不叫设计模式，那叫给自己增加阅读理解题。

## 02、是什么

访问者模式从工程视角看，核心就一句话：把“操作”从“对象结构”中请出去，放到独立的 Visitor 中。它解决的是数据结构相对固定，但对数据的操作不断扩展的场景。

很多人一上来背定义，结果越背越懵。其实先看两个角色就够了：

- Element：表示稳定的对象结构，比如员工、报表节点、AST 节点。
- Visitor：表示经常变化的操作，比如统计、报表、检查规则。

核心角色有五个：

- Visitor：访问者接口，为每种具体 Element 声明一个 visit 方法。
- ConcreteVisitor：具体访问者，实现一种统计或报表逻辑。
- Element：元素接口，声明 accept(visitor)。
- ConcreteElement：具体元素，实现 accept，把自己的 this 交给访问者的 visit 方法。
- ObjectStructure：对象结构，维护元素集合，遍历并让每个 Element 接受访问者。

比如员工体系里：

```
Element = Employee
  + accept(Visitor)

ConcreteElement = Engineer / ProductManager / Manager

Visitor = 统计访问者接口
  + visit(Engineer)
  + visit(ProductManager)
  + visit(Manager)

ObjectStructure = EmployeeStructure
```

访问者模式最不好理解的是双重分派。传统多态只能根据一个类型分派方法。比如 employee.accept(visitor) 只能分派到具体 Employee 的子类 accept 方法。那怎么同时确定具体 Visitor 的操作？答案是在具体 Element 的 accept 里，再调用 visitor.visit(this)。

```
第一次分派：employee.accept(visitor)
  -> 确定具体 Element 类型

第二次分派：visitor.visit(this)
  -> 确定具体 Visitor 操作
```

可以用字符图表示：

```
Client
  |
  v
ObjectStructure
  |
  +-- generate(Visitor)
        |
        v
Element.accept(Visitor)
  |
  +-- ConcreteElement.accept(v)
          |
          +-- v.visit(this)
                |
                v
        ConcreteVisitor.visit(ConcreteElement)
```

这里还要建立一个判断框架，看到什么代码坏味道可以联想到什么模式：

- 多个对象类型，操作经常增加 → 访问者模式
- if/else 按类型变化 → 策略模式
- 流程基本一样，部分步骤变化 → 模板方法
- 多个处理节点顺序执行 → 责任链
- 第三方接口长得完全不一样 → 适配器
- 对象创建越来越复杂 → 工厂
- 对象状态不同行为不同 → 状态模式

不要背 23 种模式，而是先识别什么在变，什么稳定。访问者模式从来不是“多类型专用”，而是“稳定结构 + 多变操作”的组合。

## 03、为什么

很多开发者学过访问者模式但不会用，问题出在三个误区。

误区一：先记模式，再找地方套。访问者模式角色多，如果拿着模式去找场景，很容易把简单逻辑复杂化。一个只有两类员工、一年只加一个统计的系统，不需要访问者。

误区二：看到多种类型就认为必须上访问者。如果操作不增加，或者类型不稳定，访问者反而增加维护成本。访问者只适合“类型稳定、操作多变”，不是“多类型多方法”的万能解。

误区三：认为抽象层越多，架构越高级。访问者把操作从元素中剥离，会增加类数量，还需要理解双重分派。如果团队看不明白，维护成本更高。

判断访问者模式是否值得使用的标准：

1. 变化是否真实存在？操作是否已经多次增加，而不是预期中的可能增加？
2. 对象结构是否稳定？员工类型、报表节点、AST 节点这类通常不会频繁变动。
3. 修改是否频繁影响旧逻辑？增加统计需求是否总是要改员工类？
4. 是否存在多种相关操作需要在同一批对象上执行？
5. 引入模式后，理解成本是否低于原来的维护成本？

简单判断公式：

```
模式收益 = 未来新增操作的成本降低 - 当前抽象复杂度增加
```

如果对象结构频繁变化，访问者模式会让你每新增一种元素，就要修改所有 Visitor，得不偿失。

> 锐评：十行代码解决的问题，不要写成一场架构发布会。访问者模式的抽象层，应该来自真实重复的痛苦，不是来自设计模式目录。

## 04、架构

访问者模式出现在“对象结构稳定、操作经常变化”这一类问题里。它和策略模式、模板方法等解决的问题不同：策略模式隔离的是“算法切换”，模板方法隔离的是“流程步骤”，访问者模式隔离的是“对一组多类型对象的操作”。

字符版问题地图：

```
需求变化
  |
  v
变化点识别：操作在增加，类型不增加
  |
  v
职责拆分：数据结构 / 操作分离
  |
  v
模式选择：访问者模式
  |
  v
接口稳定：Element.accept / Visitor.visit
  |
  v
实现扩展：新增 ConcreteVisitor 即可
```

访问者模式结构图：

```
Employee (Element)
  + accept(Visitor)
  |
  +-- Engineer.accept(v)  --> v.visit(this)
  +-- ProductManager.accept(v) --> v.visit(this)
  +-- Manager.accept(v) --> v.visit(this)

Visitor
  + visit(Engineer)
  + visit(ProductManager)
  + visit(Manager)
  |
  +-- SalaryVisitor
  +-- PerformanceVisitor
  +-- CostVisitor
```

关键：ObjectStructure 不关心访问者具体做什么，只负责把每个员工交给 Visitor。这样操作扩展时，只动 Visitor，不动 Element。

## 05、实战

### 一、业务场景

员工管理系统，员工类型只有工程师、产品经理、管理者。需要薪资统计、绩效统计、成本分析，后面还会增加福利核算、人头预算、培训费用分析等。员工类型稳定，统计操作持续增加。

### 二、第一版代码

Employee 抽象类：

```java
public abstract class Employee {
    private String name;
    private double baseSalary;

    public abstract double computeSalary();
    public abstract double computePerformance();
    public abstract double computeCost();
}
```

具体员工实现各自公式，比如工程师工资系数 1.2，产品经理 1.3，管理者 1.5。

### 三、代码开始失控

新增福利统计时，Employee 加 computeBenefit()，三个子类分别实现；新增报告导出时，再加 exportReport()。慢慢一个类有十几个方法，统计逻辑散落，薪资规则、绩效公式、成本口径全混在一起。ObjectStructure 中的统计入口也布满 instanceof 判断。

### 四、模式重构

引入访问者模式。

Employee 接口（Element）：

```java
public interface Employee {
    void accept(Visitor visitor);
    String getName();
    double getBaseSalary();
}
```

具体员工：

```java
public class Engineer implements Employee {
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
}

public class ProductManager implements Employee {
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
}

public class Manager implements Employee {
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
}
```

Visitor 接口：

```java
public interface Visitor {
    void visit(Engineer engineer);
    void visit(ProductManager productManager);
    void visit(Manager manager);
}
```

薪资统计 Visitor：

```java
public class SalaryVisitor implements Visitor {
    private double total;

    @Override
    public void visit(Engineer engineer) {
        total += engineer.getBaseSalary() * 1.2;
    }

    @Override
    public void visit(ProductManager productManager) {
        total += productManager.getBaseSalary() * 1.3;
    }

    @Override
    public void visit(Manager manager) {
        total += manager.getBaseSalary() * 1.5;
    }

    public double getTotal() { return total; }
}
```

绩效统计 Visitor：

```java
public class PerformanceVisitor implements Visitor {
    private double total;

    @Override
    public void visit(Engineer engineer) {
        total += engineer.getBaseSalary() * 0.3;
    }

    @Override
    public void visit(ProductManager productManager) {
        total += productManager.getBaseSalary() * 0.4;
    }

    @Override
    public void visit(Manager manager) {
        total += manager.getBaseSalary() * 0.5;
    }

    public double getTotal() { return total; }
}
```

成本分析 Visitor：

```java
public class CostVisitor implements Visitor {
    private double total;

    @Override
    public void visit(Engineer engineer) {
        total += engineer.getBaseSalary() * 1.8;
    }

    @Override
    public void visit(ProductManager productManager) {
        total += productManager.getBaseSalary() * 2.0;
    }

    @Override
    public void visit(Manager manager) {
        total += manager.getBaseSalary() * 2.5;
    }

    public double getTotal() { return total; }
}
```

ObjectStructure：

```java
public class EmployeeStructure {
    private final List<Employee> employees = new ArrayList<>();

    public void addEmployee(Employee employee) {
        employees.add(employee);
    }

    public void acceptAll(Visitor visitor) {
        for (Employee employee : employees) {
            employee.accept(visitor);
        }
    }
}
```

使用：

```java
EmployeeStructure structure = new EmployeeStructure();
structure.addEmployee(new Engineer(20000));
structure.addEmployee(new ProductManager(30000));
structure.addEmployee(new Manager(50000));

SalaryVisitor salaryVisitor = new SalaryVisitor();
structure.acceptAll(salaryVisitor);
System.out.println(salaryVisitor.getTotal());

CostVisitor costVisitor = new CostVisitor();
structure.acceptAll(costVisitor);
System.out.println(costVisitor.getTotal());
```

新增福利统计时，只需新增 BenefitVisitor，并实现 visit 三个方法，不需要修改 Employee 和已有 Visitor。

### 五、结构变化

传统写法：

```
EmployeeStatistics
  |
  +-- if Engineer -> computeSalary
  +-- if ProductManager -> computeSalary
  +-- if Manager -> computeSalary
  +-- if Engineer -> computePerformance
  ... 操作增加后判断继续叠加
```

重构后：

```
EmployeeStructure
  |
  v
Employee.accept(visitor)
  |
  +-- Engineer.accept(v)  --> v.visit(Engineer)
  +-- ProductManager.accept(v) --> v.visit(ProductManager)
  +-- Manager.accept(v) --> v.visit(Manager)

Visitor
  /    |     \
Salary Performance Cost
```

### 六、收益

- 新增统计操作不修改员工类，符合开闭原则。
- 统计逻辑集中在具体 Visitor 中，职责单一。
- 便于单元测试，每个 Visitor 独立测试。
- 消除 ObjectStructure 中的 instanceof 分支。

### 七、代价

- 类数量增加：每个操作对应一个 Visitor。
- 新增员工类型时，需要修改 Visitor 接口和所有实现，代价高。
- 双重分派不如直接调用直观，阅读链路变长。
- 如果 Employee 子类之间差异较大，Visitor 的 visit 方法可能写很多重复逻辑。

### 八、什么时候不要用

- 员工类型经常变，比如每个月加一种新角色，访问者会让你改所有 Visitor。
- 操作数量很少而且稳定，只有一两个统计，不值得引入。
- 类型之间差异不大，可以用简单多态替代。
- 团队对双重分派不熟悉，而且没有重复操作扩展的痛苦。

口诀：“不是把 if 藏起来，而是把操作从对象里请出去。请出去的前提是，对象结构要稳得住。”

> 锐评：如果你们公司的员工类型比统计报表还多，访问者模式会从救星变成新的修改地狱。

## 06、洞见

访问者模式背后有五个判断能力值得反复琢磨：

洞见一：设计模式真正关注的是“变化”，不是“类”。访问者模式中，Element 是变化慢的一方，Visitor 是变化快的一方，把快慢分离。

洞见二：好的抽象通常来自重复出现的变化，而不是提前想象。只有当统计需求已经第三次逼你改 Employee 类时，访问者模式才值得出现。

洞见三：设计模式最重要的价值是降低修改半径。访问者把新增操作的修改半径从“所有员工类 + 入口代码”缩小到“一个新的 Visitor”。

洞见四：架构能力不是能设计多少层，而是知道什么时候不需要设计。访问者模式自带双重分派复杂度，不能见多类型就上。

洞见五：很多框架本身就是模式的大型实践。Java 字节码处理中的 ClassVisitor、Spring 中的 BeanDefinitionVisitor 都体现了访问者思想：结构稳定，操作多变。

> 锐评：初级开发者喜欢把代码写出来，高级开发者开始考虑怎么变化，架构师最终考虑的是：哪些地方根本不值得抽象。

## 07、行动

建议分三个阶段行动。

第一阶段：先认识访问者五角色。画出 Employee、Engineer/PM/Manager、Visitor、SalaryVisitor、EmployeeStructure。

第二阶段：从自己的项目里找坏味道。哪些对象结构稳定但操作持续增加？例如订单对象上的报表、合同上的审批操作、文档树上的检查规则。

第三阶段：尝试重构。每次回答五个问题：

1. 变化点是什么？操作还是结构？
2. 不使用模式会怎样？改几个类？
3. 使用访问者增加了什么复杂度？
4. 下一次新增操作，需要修改几个地方？
5. 新增类型时，又会修改几个地方？

七天实践计划：

- Day 1：找一个包含 3 种以上稳定类型的对象结构，比如订单、员工、报表节点。
- Day 2：统计它现在有哪些操作，以及未来可能增加哪些操作。
- Day 3：把现有操作从元素类中抽到一个 Visitor 接口里，先不动业务逻辑。
- Day 4：写两个具体 Visitor，并让 ObjectStructure 遍历调用，观察双重分派流程。
- Day 5：新增第三个 Visitor，验证不修改原有元素类。
- Day 6：故意新增一个元素类型，把所有 Visitor 都改一遍，记录痛苦程度。
- Day 7：复盘：如果这个类型频繁变，回到普通多态；如果操作频繁变，保留访问者。

## 08、小结

金句：“访问者模式不是让对象结构永远不变，而是让你在操作变化时，少改几条命脉。”

真正值得学的不是访问者这个名词，而是分辨“什么在变、什么稳定”的能力。员工类型稳定，统计操作多变，就用访问者；员工类型多变，就别硬上。

如果读完这篇文章，你少在一个稳定对象体系里写了一堆 instanceof，或者少给每个员工类加了一个统计方法，这篇文章就算没白写。

## 09、链接与概念说明

- GoF：指 Gang of Four，即《设计模式：可复用面向对象软件的基础》四位作者，该书系统总结了 23 种设计模式。
- 创建型模式：解决对象怎么创建的问题，如工厂、建造者。
- 结构型模式：解决类与对象的组合问题，如适配器、装饰器、代理。
- 行为型模式：解决对象之间的职责分配与通信问题，如策略、模板方法、责任链、访问者。
- SOLID 原则：单一职责、开闭、里氏替换、接口隔离、依赖倒置。访问者模式最直接关联的是开闭原则和单一职责。
- 开闭原则：软件实体对扩展开放，对修改关闭。访问者模式通过新增 Visitor 扩展操作，不修改 Element。
- 推荐阅读：《设计模式：可复用面向对象软件的基础》《重构：改善既有代码的设计》《企业应用架构模式》。官方资料可参考 Java 文档中关于 ClassVisitor 或 BeanDefinitionVisitor 的说明。

我是老李。前阵子我接手了一个已经跑了几年的员工管理系统。系统里员工类型不多：工程师、产品经理、管理者，三种。最早只是为了算工资，每个员工类里写一个 computeSalary()，相安无事。后来业务要算绩效，于是每个类里面又加了一个 computePerformance()。再后来要做成本分析，又加 computeCost()。然后报表、人效、预算、培训支出……每个需求一进来，第一反应就是：Employee 的三个子类各改一遍。

《设计模式军体拳第24招》 访问者模式 Visitor——把数据结构与复杂操作分离

员工薪资、绩效、成本统计需求不断叠加，通过访问者模式把统计操作从稳定员工结构中剥离，降低修改半径，并明确新增类型困难的代价。

架构师

编程语言

架构设计

后端

访问者模式解决员工类型稳定、统计操作持续增加的系统失控问题。通过将操作从员工类中分离至独立Visitor，消除instanceof分支，新增统计只需新增Visitor类，符合开闭原则。但需谨慎评估：仅当操作变化频繁且类型稳定时适用，避免过度设计。案例完整演示双重分派机制与重构步骤，含使用收益和适用边界判断。

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《设计模式军体拳第24招》 访问者模式 Visitor——把数据结构与复杂操作分离-腾讯云开发者社区-腾讯云

《设计模式军体拳第24招》访问者模式 Visitor——把数据结构与复杂操作分离

《设计模式军体拳第24招》访问者模式 Visitor——把数据结构与复杂操作分离

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第24招》 访问者模式 Visitor——把数据结构与复杂操作分离

《设计模式军体拳第24招》 访问者模式 Visitor——把数据结构与复杂操作分离

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《设计模式军体拳第24招》访问者模式 Visitor——把数据结构与复杂操作分离

《设计模式军体拳第24招》访问者模式 Visitor——把数据结构与复杂操作分离