当你的对象结构拒绝修改时，访问者模式是如何破局的？

访问者设计模式深度解析

意图

访问者模式的核心目标是将算法与对象结构分离，允许在不修改现有对象结构的前提下定义新的操作。它通过双重分派机制，实现操作与对象的解耦。

现实问题

假设我们开发了一个文档处理系统，包含多种元素类型：

文本段落（TextElement）
图片（ImageElement）
表格（TableElement）

现有需求要为这些元素添加导出功能：

导出为PDF格式
生成HTML页面
转换为Markdown格式

如果直接在各个元素类中添加exportToPDF(), toHTML()等方法，会导致：

元素类职责变得臃肿
每次新增格式都要修改所有元素类
难以维护格式转换的公共逻辑

java 复制代码

// 传统实现的问题示例
class TextElement {
    void exportToPDF() { /* ... */ }
    String toHTML() { /* ... */ }
    String toMarkdown() { /* ... */ }
}

解决方案

访问者模式通过引入两个关键接口：

Visitor：声明访问各种元素的visit方法
Element：定义接受访问者的accept方法

将格式转换逻辑外移到独立的访问者类中，实现操作与数据结构的解耦。

现实场景类比

想象超市购物场景：

商品（元素）：苹果、牛奶、衣服
收银员（访问者）：计算价格、打印小票、库存扣减
购物车（对象结构）：承载商品集合

收银员处理不同商品的方式，类似于访问者处理不同元素的操作。

模式结构

访问者设计模式角色描述

角色	职责与特征
Visitor（访问者接口）	1. 声明一系列以具体元素类为参数的访问方法（如 `visit(ElementA)`、`visit(ElementB)`） 2. 方法名称可相同，但参数类型必须不同（依赖语言重载支持） 3. 访问方法知晓具体元素的内部细节（如调用 `e.featureB()`）
Concrete Visitor（具体访问者）	1. 实现 `Visitor` 接口中定义的所有访问方法 2. 为不同具体元素类（如 `ElementA`、`ElementB`）提供不同的行为实现 3. 包含与具体元素交互的业务逻辑（如格式转换、计算逻辑）
Element（元素接口）	1. 声明 `accept(v: Visitor)` 方法，用于接收访问者对象 2. 定义元素与访问者交互的抽象协议
Concrete Element（具体元素）	1. 实现 `Element` 接口的 `accept` 方法 2. 必须重写 `accept` 方法，并在其中调用访问者的对应方法（如 `v.visit(this)`） 3. 提供自身特征方法供访问者调用（如 `featureA()`、`featureB()`）
Client（客户端）	1. 作为对象结构（如集合、组合树）的代表，持有元素集合 2. 通过抽象接口与元素交互，无需知道具体元素类型 3. 组合访问者和元素（如 `element.accept(new ConcreteVisitor())`）

关键补充说明

双重分派机制 ：

通过 element.accept(visitor) 和 visitor.visit(element) 的两次动态绑定，实现操作与元素的动态匹配。
元素类的约束：
- 所有具体元素子类必须显式实现 accept 方法，即使父类已提供默认实现。
- 元素类需向访问者暴露必要的方法（如 featureB()），可能破坏封装性。
客户端的角色 ：

客户端不直接操作具体元素，而是通过访问者与对象结构的抽象接口交互，符合依赖倒置原则。

代码示例

java 复制代码

// 元素接口
interface DocumentElement {
    void accept(ExportVisitor visitor);
}

// 具体元素
class TextElement implements DocumentElement {
    public void accept(ExportVisitor visitor) {
        visitor.visit(this);
    }
}

class ImageElement implements DocumentElement {
    public void accept(ExportVisitor visitor) {
        visitor.visit(this);
    }
}

// 访问者接口
interface ExportVisitor {
    String visit(TextElement text);
    String visit(ImageElement image);
    String visit(TableElement table);
}

// 具体访问者
class HtmlExportVisitor implements ExportVisitor {
    public String visit(TextElement text) {
        return "<p>" + text.getContent() + "</p>";
    }
    
    public String visit(ImageElement image) {
        return "<img src='" + image.getUrl() + "'>";
    }
}

// 对象结构
class Document {
    private List<DocumentElement> elements = new ArrayList<>();
    
    public void export(ExportVisitor visitor) {
        elements.forEach(e -> e.accept(visitor));
    }
}

// 客户端使用
Document doc = new Document();
doc.add(new TextElement());
doc.add(new ImageElement());

ExportVisitor htmlExporter = new HtmlExportVisitor();
String html = doc.export(htmlExporter);

适用场景

对象结构稳定但需要频繁新增操作
需要对同一对象结构进行多种无关操作
需要分离核心业务逻辑与辅助功能
需要跨多个类层次结构的操作

实现步骤

定义元素接口：添加accept方法

java 复制代码

public interface Element {
    void accept(Visitor visitor);
}

创建访问者接口：为每个元素类型声明visit方法

java 复制代码

public interface Visitor {
    void visitText(TextElement text);
    void visitImage(ImageElement image);
}

实现具体访问者

java 复制代码

public class PdfVisitor implements Visitor {
    public void visitText(TextElement text) {
        // PDF转换逻辑
    }
}

构建对象结构

java 复制代码

public class Report {
    private List<Element> elements = new ArrayList<>();
    
    public void generate(Visitor visitor) {
        elements.forEach(e -> e.accept(visitor));
    }
}

客户端组合使用

java 复制代码

Report report = new Report();
Visitor pdfGen = new PdfGenerator();
report.generate(pdfGen);

优缺点分析

优点：

符合开闭原则：新增访问者无需修改元素
职责单一：相关操作集中存放
便于跨类层次操作
访问者可以累积状态

缺点：

破坏封装性：需要暴露元素内部细节
增加新元素类型困难
可能违反里氏替换原则

与其他模式的关系

模式	关联点	区别点
组合模式	常配合处理树形结构	组合关注结构，访问者关注操作
装饰者模式	都扩展功能	装饰者增强对象，访问者新增操作
策略模式	都封装算法	策略单个算法，访问者多元素处理

最佳实践组合：

访问者 + 迭代器：遍历复杂结构
访问者 + 组合：处理树形结构
访问者 + 解释器：在AST上执行操作

访问者模式特别适合处理编译器场景：

抽象语法树（AST）遍历
代码格式化
类型检查
代码优化
字节码生成

通过合理运用访问者模式，可以使系统获得更好的扩展性和维护性，特别是在需要为复杂对象结构添加多种操作时，能显著降低代码耦合度。

最后

如果文章对你有帮助，点个免费的赞鼓励一下吧！关注gzh:加瓦点灯，每天推送干货知识！