c# - Acyclic Visitor 相对于 Switch On 类型命令的优势

Question

访问者模式在元素层次结构稳定且操作这些元素所需的功能经常变化的情况下很有用。

在元素层次结构发生变化的情况下，访问者模式会受到耦合的影响，这会强制重建元素和功能层次结构中的所有类。

为了对此进行改进，Acyclic Visitor 使用了额外的抽象级别，在顶部有一个空的 Visitor 接口(interface)，并为元素层次结构中的每个类提供了一个特定的接口(interface)。

假设有两个具体的元素类型 IntMessage 和 StringMessage，非循环访问者看起来像这样:

abstract class Message // parent for the model/element/data classes
{
    public abstract void Accept(Visitor visitor);
}
class IntMessage : Message  // concrete element type 1
{
    internal int data;

    public override void Accept(Visitor visitor)
    {
        // check if the concrete visitor knows how to work on IntMessage
        if (visitor is IntMessageVisitor)
            (visitor as IntMessageVisitor).Visit(this);   
    }
}
class StringMessage : Message  // concrete element type 2
{
    internal String msg;
    public override void Accept(Visitor visitor)
    {
        // check if the concrete visitor knows how to work on StringMessage
        if (visitor is StringMessageVisitor)
            (visitor as StringMessageVisitor).Visit(this);
    }
}


interface Visitor  // empty parent interface for acyclic visitor
{
}

interface IntMessageVisitor : Visitor
{
    void Visit(IntMessage message);
}
interface StringMessageVisitor : Visitor
{
    void Visit(StringMessage message);
}

一个具体的访问者将从它知道如何访问的元素类型的所有特定访问者接口(interface)继承。这样做的好处是，在将新类添加到元素层次结构的情况下，只有需要访问新元素的具体访问者才会被迫更改。

class PrintVisitor : StringMessageVisitor, IntMessageVisitor
{
        public void Visit(IntMessage message)
        {
            Console.WriteLine("Int message with data = " + message.data);
        }
        public void Visit(StringMessage message)
        {
            Console.WriteLine("String message with data = " + message.msg);
        }
}

足够的设置，让我们继续这个问题。

问题是，考虑到非循环访问者模式的复杂性，它是否比使用带有 switch-on-type 的简单命令有任何真正的好处？

例如，我们可以将 PrintVisitor 重写为以下打印命令:

class PrintCommand : Command
{
    public void Execute(Message message)
    {
        // switch on type
        if (message.GetType() == typeof(IntMessage))
        {
            Console.WriteLine("Int message with data = " + ((IntMessage)message).data);
        }
        else
        if (message.GetType() == typeof(StringMessage))
        {
            Console.WriteLine("String message with data = " + ((StringMessage)message).msg);
        }
    }
}

如果将来在元素层次结构中添加了新类(例如 DateMessage )，那么仍然只有想要在新元素类型上工作的命令需要更改。最终的设计会简单得多，没有多重接口(interface)继承和双重分派(dispatch)，代价是使用运行时类型信息而不是虚函数。

就 OCP 和 future 的维护而言，与非循环访问者相比，开启类型似乎没有额外的成本。

是否有任何理由更喜欢 ACyclic Visitor 而不是带有 switch-on-type 的命令？

Answer 1

没有明确的答案。答案取决于您的具体情况。您的示例相对简单，因为它只涉及单一类型的替代方案，而不是类型的替代方案。族。 typical example of a Visitor展示了使用不同的访问者来处理树中多个 不同类型的家族。一个很好的例子是将 XML 呈现为 HTML、PDF 或 word 文档的访问者。这些访问者中的每一个都处理一系列元素。

在这个简单的示例中，Visitor 不是很有用。它以(显着)复杂性为代价增加了类型安全性。

自从 C# 6 引入模式后，所有这些代码都可以大大减少。在 C# 9 中，Execute 可以是:

public static void Execute(Message message)
{
    var text=message switch { 
                 IntMessage intM=>$"blah {intM.data}", 
                 StringMessage stM=> $"blah {stM.msg}", 
                 _ => throw new ArgumentException($"Unknown type {message.GetType()}",
                                                  nameof(message))
    };
    Console.WriteLine(text);
}

首先是泛型，然后是动态，现在是像模式匹配这样的功能特性，极大地减少了需求，同时大大简化了代码很多。函数式语言很少需要访问者，因为编译器可以轻松推断类型并检测遗漏的情况。

如果 C# 已经区分联合，这是一个热切期待但自 C# 7 以来一直推迟的功能，那么甚至不需要 default case。编译器本身会识别缺失的情况。

在这个例子中，更改可以本地化到这个方法。

虽然在渲染器示例中，每个具体访问者都必须处理相同的众所周知的元素集。这些元素具有众所周知的结构。在这种情况下需要访客吗？

也许吧，但它可以简化很多。

模式匹配等功能特性可以轻松处理多种元素类型和多个渲染器。对元素结构的任何更改都可以限制在模式匹配代码中，将特定于渲染器的调用转发给具体的渲染器访问者。

除非它不能。在最简单的情况下，某些 类型的渲染器可能需要不同的方式来处理元素。一些渲染器可能需要多次访问元素。

或者在可能的情况下，数据的大小可能需要不同的策略。当想要导出 1M 行时，最好的选择是流式传输呈现的结果，而不是将它们缓存在内存中。 Excel 虽然是一个 ZIP 包，因此在导出之前需要收集结果。在这种情况下，即使结构和渲染器相同，不同的数据大小也需要不同的实现。