c# - 树遍历 API 的访问者模式与 LINQ 风格的流畅语法

Question

我正在考虑重构一个开源项目，Afterthought , 使其使用起来更直观。基本思想是，开发人员在 Afterthought 中创建修改将修改特定的 .NET 类型，并有机会修改类型本身，以及属性、方法、事件、构造函数等的列表(树)。我在内部使用的 API Microsoft CCI Metadata在他们的 API 中广泛使用访问者模式，因此我在 Afterthought 中采用了类似的方法，如下所示:

public override void Amend()
{
    // Amend the type here, add properties, add methods, etc.
}

public override void Amend<TProperty>(Property<TProperty> property)
{
    // Amend properties here
    if (property.Name == "Result")
    {
        // Modify Result property
    }
}

public override void Amend(Method method)
{
    // Amend methods here
    if (method.Name == "Add")
    {
        // Modify Add method
        method.Implement(TInstance instance, int x, int y) => x + y);
    }
}

但是，我发现访问者模式实际上最终将解决目标问题(例如检测类库)的代码重新分配到一系列专注于树的各个方面的不同方法中。这对于创建 API 的开发人员来说很容易实现，但消费者必须以一种有点不自然的方式传播他们的代码。所以我提出了一个问题，与仅将树公开为列表并利用 LINQ 风格的方法相比，访问者模式有什么好处？

这是我正在考虑的替代语法:

public override void Amend()
{
    // Do everything here, possibly calling methods just to organize the code

    // Modify Add method
    Methods.Named("Add").WithParams<int, int>()
        .Implement((instance, x, y) => x + y);
}

因此，在这种情况下，修正案的作者可以通过与公开流畅/LINQ API 的列表交互而不是重写方法，将所有代码写在一个地方(或他们选择的地方)。显然，这种方法的性能稍差(更多迭代等)，但除此之外，还有哪些缺点？

Answer 1

访问者模式可帮助您避免创建将测试所访问元素类型的 if 或 switch 语句。避免这些语句通常被认为是一种好的做法。如果您实现的操作没有区分可以访问的各种可能类型的元素，那么，是的，访问者模式不会给您带来任何优于 your alternative approach 任何其他方法的优势。

问题可能出在对访问者模式的理解上:它主要是在不提供此功能的语言中实现双分派(dispatch)，或者(这是C#的情况)使用双分派(dispatch)带来相当大的影响性能问题。这与遍历树无关。它甚至可以用于不形成层次结构的类。 GoF书上说遍历算法可以由Visitor自己实现，也可以由被访问元素实现，甚至可以由客户端实现。

编辑:我再次仔细阅读了您的问题，我认为您的方法可以说是访问者模式的替代实现，其中访问者不是一个类，而是一组 lambda 函数。