# 概述
访问者模式是一种行为设计模式，它允许我们向已有的类层次结构中添加新的操作，而无需修改这些类本身。这听起来有点抽象。

访问者模式的核心思想就是**将算法（操作）与对象结构（数据）分离**。
![Gemini_Generated_Image_d9sn1jd9sn1jd9sn.png](https://developer.qcloudimg.com/http-save/yehe-1367556/b0844d4ee07c1618edc9b251a6e42d1e.png)
它引入了一个“访问者”对象，这个对象可以“访问”结构中的每个元素，并对它们执行操作。而元素对象只需要接受访问者的访问，把具体的操作委托给访问者。
# 遇到的问题
举个例子。
我们有一个稳定的形状类层次结构（比如`Shape`接口，有`Circle`, `Square`, `Triangle`等实现）。现在，我们需要不断为这个结构添加新的、横切性的操作，比如：
1. 计算面积 (`CalculateArea`)
2. 计算周长 (`CalculatePerimeter`)
3. 导出为XML (`ExportXML`)
4. 序列化为JSON (`SerializeToJSON`)
5. 渲染到画布 (`Render`)

**传统做法会有下面这些问题**
- **违反开闭原则**：每次新增一个操作，我们都要打开并修改每一个具体的形状类。这就像每次给房子加个新功能，都得把承重墙砸开一样，风险很高。
- **职责混杂**：形状类本应只关心自己的几何属性（如半径、边长），但现在却要混杂进各种业务逻辑（计算、导出、渲染）。一个类变得臃肿，难以维护。
- **难以复用操作逻辑**：如果计算面积的逻辑也适用于其他非形状的图形（比如一个复杂的路径），我们很难直接复用。

更糟糕的是，如果这个形状类层次是第三方库提供的，我们根本无法修改源代码。
# 解决方案
访问者模式给出的方案是：**把操作抽离出来，变成独立的“访问者”对象**。
![双分派序列图.png](https://developer.qcloudimg.com/http-save/yehe-1367556/b72a0e5126aae9417384ad744b4b4487.png)
具体怎么做呢？
1. **定义访问者接口**：这个接口声明了一组 `VisitXxx` 方法，每个方法对应一种具体的元素类型（比如 `VisitCircle(*Circle)`, `VisitSquare(*Square)`）。

2. **在元素接口中添加一个“接受”访问的方法**：在每个元素接口（如`Shape`）中，添加一个 `Accept(Visitor)` 方法。这个方法是整个模式的关键。

3. **让具体元素实现Accept方法**：在每个具体的形状类（如`Circle`）中，实现`Accept`方法。它的实现非常简单：调用访问者对象的、对应自己类型的方法，并把自己（`this`）传进去。比如 `func (c *Circle) Accept(v Visitor) { v.VisitCircle(c) }`。

4. **实现具体的访问者**：当我们需要一个新的操作时，就创建一个新的结构体来实现`Visitor`接口。比如 `AreaCalculator` 结构体，它实现 `VisitCircle`, `VisitSquare`等方法，在每个方法里实现对应形状的面积计算逻辑。

这个过程的精妙之处在于 **“双分派”（Double Dispatch）**。
第一次分派是客户端调用 `shape.Accept(visitor)`，根据 `shape` 的实际类型（是圆还是方）决定调用哪个 `Accept` 实现。

第二次分派发生在 `Accept` 方法内部，它调用 `visitor.VisitCircle(this)`，根据 `visitor` 的实际类型（是算面积的还是导XML的）决定执行哪个操作。

通过这两次跳转，我们最终把“什么元素”和“什么操作”完美地绑定在了一起，而无需在元素类里写任何 `if-else` 或 `switch-case`。
# 应用场景
主要有这么几种情况：
- **需要对一个复杂对象结构（如组合树、集合）中的所有元素执行某种操作**。比如，遍历一个文件系统目录树（包含文件和文件夹），进行病毒扫描、计算总大小、查找特定文件等。访问者模式让你可以轻松添加新的遍历操作，而不用改动文件和文件夹类。

- **一些操作只与类层次结构中的部分类强相关，而与其他类无关**。比如，在一个编译器抽象语法树（AST）中，我们有变量声明、函数调用、赋值语句等节点。类型检查、代码优化、代码生成这些操作，可能只关心某几类节点。访问者模式允许我们为每个操作创建一个访问者，只实现它关心的节点方法，其他方法留空即可。

- **清理辅助业务逻辑，让核心类保持干净**。当核心的数据类（元素）被各种杂七杂八的工具方法污染时，可以把这些工具方法抽离成独立的访问者类。这样，数据类只保留核心数据和结构，职责更清晰。

但也要注意，如果元素类层次结构不稳定，经常需要添加新的元素类型，那么访问者模式就不太合适了，因为每加一个新元素，就需要修改所有的访问者接口和实现。
# 代码示例
Go没有传统OOP的继承，但我们用接口和结构体组合也能很好地实现。关键在于实现“双分派”。

1. **定义元素接口和具体元素**：首先，我们有一个稳定的形状层次结构。

```
// shape.go - 元素接口
package main

type Shape interface {
    GetType() string
    Accept(Visitor) // 关键方法：接受一个访问者
}

// circle.go - 具体元素
type Circle struct {
    Radius float64
}
func (c *Circle) GetType() string {
    return "Circle"
}
func (c *Circle) Accept(v Visitor) {
    v.VisitCircle(c) // 双分派：调用访问者中对应自己的方法
}

// square.go - 具体元素
type Square struct {
    Side float64
}
func (s *Square) GetType() string {
    return "Square"
}
func (s *Square) Accept(v Visitor) {
    v.VisitSquare(s)
}

// triangle.go - 具体元素
type Triangle struct {
    Base, Height float64
}
func (t *Triangle) GetType() string {
    return "Triangle"
}
func (t *Triangle) Accept(v Visitor) {
    v.VisitTriangle(t)
}
```
2. **定义访问者接口**：这个接口声明了所有可能的访问方法。

```
// visitor.go - 访问者接口
type Visitor interface {
    VisitCircle(*Circle)
    VisitSquare(*Square)
    VisitTriangle(*Triangle)
}
```

3. **实现具体访问者**：现在，我们可以轻松地添加新操作，而无需改动上面的 `Shape` 和具体形状。

```
// area_calculator.go - 具体访问者：计算面积
type AreaCalculator struct {
    TotalArea float64
}
func (a *AreaCalculator) VisitCircle(c *Circle) {
    area := 3.14 * c.Radius * c.Radius
    fmt.Printf("Calculating area for circle (radius=%.2f): %.2f\n", c.Radius, area)
    a.TotalArea += area
}
func (a *AreaCalculator) VisitSquare(s *Square) {
    area := s.Side * s.Side
    fmt.Printf("Calculating area for square (side=%.2f): %.2f\n", s.Side, area)
    a.TotalArea += area
}
func (a *AreaCalculator) VisitTriangle(t *Triangle) {
    area := 0.5 * t.Base * t.Height
    fmt.Printf("Calculating area for triangle (base=%.2f, height=%.2f): %.2f\n", t.Base, t.Height, area)
    a.TotalArea += area
}

// xml_exporter.go - 具体访问者：导出XML
type XMLExporter struct{}
func (x *XMLExporter) VisitCircle(c *Circle) {
    fmt.Printf(`<Circle radius="%.2f"/>`+"\n", c.Radius)
}
func (x *XMLExporter) VisitSquare(s *Square) {
    fmt.Printf(`<Square side="%.2f"/>`+"\n", s.Side)
}
func (x *XMLExporter) VisitTriangle(t *Triangle) {
    fmt.Printf(`<Triangle base="%.2f" height="%.2f"/>`+"\n", t.Base, t.Height)
}
```

4. **客户端使用**：

```
func main() {
    // 我们的图形结构
    shapes := []Shape{
        &Circle{Radius: 5},
        &Square{Side: 4},
        &Triangle{Base: 3, Height: 6},
    }

    // 操作1：计算总面积
    areaCalc := &AreaCalculator{}
    for _, shape := range shapes {
        shape.Accept(areaCalc) // 关键调用
    }
    fmt.Printf("Total area: %.2f\n\n", areaCalc.TotalArea)

    // 操作2：导出为XML
    xmlExporter := &XMLExporter{}
    fmt.Println("Exporting to XML:")
    for _, shape := range shapes {
        shape.Accept(xmlExporter)
    }
}
```
![Gemini_Generated_Image_ivb4npivb4npivb4.png](https://developer.qcloudimg.com/http-save/yehe-1367556/0e43de7562c77d47e7fb9fb68012d9e8.png)
# 优缺点
**优点：**

- **开闭原则的典范**：这是最大的优点。你可以引入新的访问者（新操作）来扩展功能，而无需修改现有的元素类。这对于维护稳定的核心数据结构（如编译器AST、UI组件树）尤其有价值。

- **单一职责原则**：访问者模式将相关的操作集中到一个类中（例如所有面积计算逻辑都在 `AreaCalculator` 里），而不是散落在各个元素类中。这使得算法更容易管理和复用。

- **便于在遍历时收集信息**：访问者对象可以在遍历整个复杂结构的过程中累积状态。比如上面的 `AreaCalculator` 可以累加总面积，或者一个“查找最大元素”的访问者可以记录当前找到的最大值。

- **访问者可以跨越不同的类层次工作**：只要这些类都实现了相同的 `Accept` 方法（即属于同一个元素接口体系），一个访问者就可以处理它们。这提供了另一种形式的“多态”。

**缺点：**
- **元素类层次结构必须稳定**：这是最大的限制。如果你经常需要向元素层次中添加新的具体类（比如新增一个 `Pentagon` 五边形），那么你就必须更新所有的访问者接口和现有的具体访问者类，为它们添加 `VisitPentagon` 方法。这在频繁变动的系统中是灾难。

- **可能破坏封装**：访问者为了完成工作，常常需要访问元素的内部状态（比如圆的半径）。这可能需要将元素的字段设为公开（public），或者提供Getter方法，这在一定程度上破坏了封装性。

- **增加了复杂性**：对于简单的、操作很少的结构，使用访问者模式可能显得“杀鸡用牛刀”，反而让代码更难理解。双分派的机制对于新手来说也需要时间消化。

- **访问者会与具体元素类耦合**：访问者接口直接依赖于所有具体元素类。这违反了“依赖倒置原则”（依赖于抽象，而非具体）。不过在这种模式下，这是一种有意的、可接受的权衡。
# 总结
所以，当我们面对一个**结构稳定但操作多变**的系统时——比如那个图形库、编译器前端、文档对象模型（DOM）——访问者模式提供了一种非常优雅的扩展方案。
它有点像我们团队制定的一种“协议”或“插件机制”。核心的数据结构（元素）只负责声明“我可以被访问”（`Accept`方法），而把“你来做什么”（具体操作）完全交给外部的访问者。这种架构上的分离，使得核心模块非常稳定，而功能模块可以独立且灵活地扩展。

访问者模式是一种行为设计模式，它允许我们向已有的类层次结构中添加新的操作，而无需修改这些类本身。这听起来有点抽象。

访问者设计模式-使用go语言实现

十倍工程师

编程语言

架构设计

后端

访问者模式是一种行为设计模式，通过将算法与对象结构分离，允许在不修改现有类的情况下添加新操作。它通过双分派机制实现，适用于稳定类层次结构但需要频繁扩展操作的场景，如编译器AST处理、图形计算等。该模式遵循开闭原则，但要求元素类结构稳定，否则维护成本较高。

数据结构

文件系统

编译器

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

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

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

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

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

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

社区新版编辑器体验调研

访问者设计模式-使用go语言实现-腾讯云开发者社区-腾讯云

访问者设计模式-使用go语言实现

访问者设计模式-使用go语言实现

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐