17370845950

Go中无法直接套用经典访问者模式，因缺乏方法重载与子类型多态；应让每个结构体显式实现值接收器的Accept方法，并在Visitor接口中为每种元素定义独立Visit方法，以保障编译期类型安全与可扩展性。

访问者模式在 Go 中为何不能直接套用经典实现

Go 没有方法重载、没有子类型多态（如 Java 的 visit(ConcreteElementA) 和 visit(ConcreteElementB) 重载），所以照搬 GoF 访问者模式会导致类型断言泛滥或反射滥用，失去静态类型保障和可读性。

真正可行的扩展方式是：让每个结构体显式实现 Accept 方法，并在其中调用访问者对应的具体处理函数——本质是「双分派的手动模拟」。

• 每个 Element 类型必须定义 Accept(v Visitor) 方法
• Visitor 接口只声明一个通用方法（如 Visit(e interface{})），但实际使用时靠类型判断分支
• 更推荐的是：为每种 Element 在 Visitor 接口中定义独立方法，由具体访问者实现；Accept 内部直接调用该方法，避免运行时类型检查

如何为 struct 添加 Accept 方法并保持类型安全

关键不是“让结构体支持任意访问者”，而是让结构体知道自己能被哪些访问者处理。因此 Accept 方法签名应限定访问者接口类型，而非 interface{}。

例如，若定义了 ShapeVisitor 接口，则所有形状结构体的 Accept 都只接受该接口：

type Circle struct {
    Radius float64
}

func (c Circle) Accept(v ShapeVisitor) {
    v.VisitCircle(c) // 直接传值，无需指针（除非需修改）
}

这样做的好处：

• 编译期检查访问者是否实现了 VisitCircle
• 避免在访问者内部做 if circle, ok := e.(Circle) 这类易漏分支
• 新增一种 Shape 类型时，只需补全所有已存在 ShapeVisitor 实现的对应方法，IDE 能提示缺失

Visitor 接口设计：按元素类型拆分方法 vs 统一 Visit 方法

统一 Visit(e interface{}) 看似灵活，实则破坏类型安全，且无法利用 Go 的接口隐式实现特性。应优先选择按元素类型拆分的方法设计。

对比：

• ❌ 不推荐：type Visitor interface { Visit(e interface{}) } → 必须在内部做类型断言，新增元素类型不触发编译错误
• ✅ 推荐：type ShapeVisitor interface { VisitCircle(Circle); VisitRect(Rect); VisitTriangle(Triangle) } → 新增 Shape 类型后，所有实现了该接口的访问者都会因缺少方法而报错，强制扩展

如果访问者逻辑差异大（比如有的只序列化、有的只校验），可定义多个细粒度接口：

type Serializer interface {
    SerializeCircle(Circle)
    SerializeRect(Rect)
}

type Validator interface {
    ValidateCircle(Circle)
    ValidateRect(Rect)
}

常见陷阱：指针接收器与值接收器导致 Accept 行为不一致

若结构体用指针接收器实现 Accept，但你传入的是值（如 circle.Accept(v)），Go 会自动取地址；但如果该结构体不可寻址（如字面量、map 中的值），就会编译失败或 panic。

更隐蔽的问题是：若 Accept 是指针接收器，而访问者方法期望接收指针（如 VisitCircle(*Circle)），但你传的是值，就会类型不匹配。

• 统一约定：所有 Accept 使用值接收器，所有 VisitXxx 方法参数也用值类型（除非需要修改原始数据）
• 若确实需要修改元素状态，Accept 和对应 VisitXxx 都改用指针，且调用时确保传入可寻址值（如 &circle）
• 切勿混用：比如 func (c *Circle) Accept(v V) { v.VisitCircle(c) } 配合 func (v *MyV) VisitCircle(c Circle) —— 类型不匹配，编译失败

最易被忽略的一点：当结构体嵌入匿名字段且希望复用父级 Accept 时，Go 不会自动提升，必须手动重写 Accept 并委托，否则访问者根本收不到通知。