C++访问者模式演进：从经典实现到现代变体

1. 访问者模式基础回顾

访问者模式是GoF经典设计模式中行为型模式的代表之一，它允许在不修改已有类结构的前提下定义新的操作。传统实现通常包含以下几个核心组件：

• Visitor接口：声明一组visit方法，对应每个可访问元素类型
• ConcreteVisitor：实现接口的具体访问者，包含实际业务逻辑
• Element接口：定义accept方法接收访问者
• ConcreteElement：实现元素接口的具体类

这种模式在编译器设计、抽象语法树处理等场景中表现尤为出色。比如在语法树遍历时，我们可以为类型检查、代码优化等不同操作创建独立的访问者，而无需反复修改语法树节点类。

但传统实现存在一个明显约束：visit方法的重载依赖于具体元素类型，这意味着每增加一种新元素类型，所有访问者接口和实现都需要同步修改。这种设计在类型系统稳定的场景尚可接受，但在需要频繁扩展元素类型的系统中就显得力不从心。

2. 经典实现的问题分析

让我们通过一个实际案例来暴露传统访问者模式的痛点。假设我们正在开发文档处理系统，基础元素类型包括：

cpp复制class DocumentElement {
public:
    virtual void accept(Visitor& v) = 0;
};

class Paragraph : public DocumentElement { /*...*/ };
class Image : public DocumentElement { /*...*/ };
class Table : public DocumentElement { /*...*/ };

当我们需要新增一个Video元素类型时，必须：

1. 修改Visitor基类接口，添加visit(Video&)纯虚函数
2. 修改所有现有Visitor实现类，补充对新元素类型的处理
3. 重新编译整个Visitor层次结构

这种"牵一发而动全身"的修改方式显然违反了开闭原则。更糟糕的是，在某些大型系统中，访问者实现可能分布在多个模块甚至不同团队维护的代码库中，协调这些修改将带来巨大的沟通成本。

3. 类型安全的变体实现

3.1 动态类型检查方案

第一种改进思路是利用C++的RTTI机制实现动态类型检查。我们保持