非循环访问者相对于具有开启类型的命令的优势

Question

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

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

为了改进这一点，非循环访问者使用了一个额外的抽象级别，顶部有一个空的访问者接口，元素层次结构中的每个类都有一个特定的接口。

假设有两个具体的元素类型 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);
}

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

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);
        }
}

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

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

例如，我们可以将 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 ），那么仍然只有想要处理新元素类型的命令需要更改。 最终的设计会更简单，没有多重接口继承和双重分派，代价是使用运行时类型信息而不是虚函数。

似乎就 OCP 和未来的维护而言，对于非循环访问者的切换类型没有额外的成本。

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

Answer 1

没有明确的答案。 答案取决于您的具体情况。 你举的例子也比较简单，因为它仅涉及替代单一类型，类型不替代家庭。 访问者的典型示例展示了使用不同的访问者来处理树中多种不同类型的族。 一个很好的例子是将 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);
}

第一泛型，然后dynamic和像现在的模式匹配功能特征都降低了需要极大，同时简化了代码很多。 函数式语言很少需要访问者，因为编译器可以轻松推断类型并检测遗漏的情况。

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

在此示例中，更改可以本地化为仅此方法。

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

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

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

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

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

Answer 2

早在 2005 年，Bob Martin 就在博客中讨论了这个问题： http : //butunclebob.com/ArticleS.UncleBob.VisitorVersusInstanceOf 。 关于类型检查（非访问者）方法，他说，

...有些事情我不喜欢这个。 一方面，随着越来越多的导数被添加到系统中，if/else 语句链将无限增长。 执行 [type-checking] 语句需要时间，平均而言，我们将不得不执行其中的一半……这意味着运行时复杂度为 O(n)，其中 n 是导数的数量。

他提到的派生类是“可访问的”子类，在 OP 中将是Message子类。 他的论点归结为表现。 这并不意味着非循环访问者总是比普通的旧类型检查更可取。

我并不是要说明应该始终使用非循环访问者。 事实上，我们讨论过的每种形式都适用于各种情况。 我使用以下决策表：

	上下文层次结构更改	访问者层次结构更改	效率很重要
if/else 的 instanceof	不	不	不
游客	不	是的	是的
非循环访问者	是的	是的	是的

将类型检查逻辑隐藏在 OP 中所示的抽象后面可以解决有关层次结构更改的问题，这意味着唯一剩下的问题是性能。 与 if/else 链中的许多相比，非循环访问者只需要一种类型检查。