c# - 当代码依赖于两个对象的子类型时，是否有设计模式来处理

Question

我会尽可能明确，以防有比回答我的问题更好的解决方案。

我在 C# 中工作。

我有一个报告模板，其中可以包含任意数量的已启用“功能”。功能可能是信息表、饼图/条形图、列表等。我正在将报告生成为文本文件或 PDF(将来可能有其他选项)。

到目前为止，我有一个 IFeature 接口(interface)，以及实现它的一些功能类型:ChartFeature、ListFeature 等。我从数据库中读取启用的功能列表，并将每个功能连同数据 ID 传递给一个方法，该方法返回一个填充的正确类型的 IFeature。

我还有一个 IReportWriter 接口(interface)，由 TextReportWriter 和 PdfReportWriter 实现。该接口(interface)有一个方法:AddFeature(IFeature)。

问题是每个 writer 中的 AddFeature 最终看起来像:

public void AddFeature(IFeature)
{
    InsertSectionBreakIfNeeded();

    if(IFeature is TableFeature)
    {
        TableFeature tf = (TableFeature)feature;
        streamWriter.WriteLine(tf.Title);
        for(int row=0; row < tf.Data.First.Length; row++)
        {
            for(int column=0; i < tf.Data.Length; i++)
            {
                if(i != 0)
                {
                    streamWriter.Write("|");
                }
                streamWriter.Write(feature.Data[column][row]);
            }
        }
    }
    else if(IFeature is ListFeature)
    {
        ListFeature lf = (ListFeature)feature;
        streamWriter.Write(lf.Title + ": ");
        bool first = true;
        foreach(var v in lf.Data)
        {
            if(!first)
            {
                streamWriter.Write(", ");
            }
            else
            {
                first = false;
            }
            streamWriter.Write(v);
        }
    }
    ...
    else
    {
        throw new NotImplementedException();
    }
    sectionBreakNeeded = true;
}

在 PDF 编写器中，上述内容将被修改以生成 PDF 表格单元格、文本框等。

这感觉很糟糕。我更喜欢它作为 AddFeature(ListFeature){...}, AddFeature(ChartFeature) 因为至少在编译时检查了它，但实际上它只是移动了问题所以现在如果 IReportWriter 我正在调用 if(feature is ...)。

将显示代码移到功能中恰恰扭转了问题，因为它需要知道它应该编写纯文本还是 PDF。

有什么建议吗，还是我最好只使用我所拥有的而忽略我的感受？

编辑:填写一些条件可以让人们更好地了解正在发生的事情。不必太在意这些示例中的确切代码，我只是随手写下的。

Answer 1

您的问题的一般情况称为双分派(dispatch) - 您需要根据两个参数的运行时类型分派(dispatch)到一个方法，而不仅仅是一个(“this”指针)。

处理此问题的一种标准模式称为访问者模式。它的描述可以追溯到最初的设计模式书籍，因此那里有很多示例和分析。

基本思想是您有两个通用事物 - 您有元素(它们是您正在处理的事物)和访问者，它们对元素进行处理。您需要对它们进行动态分派(dispatch) - 因此实际调用的方法因元素和访问者的具体类型而异。

在 C# 中，有点像您的示例，您将定义一个 IFeatureVisitor 接口(interface)，如下所示:

public interface IFeatureVisitor {
    void Visit(ChartFeature feature);
    void Visit(ListFeature feature);
    // ... etc one per type of feature
}

然后，在您的 IFeature 接口(interface)中，添加一个“Accept”方法。

public interface IFeature {
    public void Accept(IFeatureVisitor visitor);
}

您的功能实现将像这样实现 Accept 方法:

public class ChartFeature : IFeature {
    public void Accept(IFeatureVisitor visitor) {
        visitor.Visit(this);
    }
}

然后您的报告编写者将实现 IVisitor 接口(interface)并在每种类型中执行它应该执行的任何操作。

要使用它，它看起来像这样:

var writer = new HtmlReportWriter();
foreach(IFeature feature in document) {
    feature.Accept(writer);
}
writer.FinishUp();

其工作方式是对 Accept 的第一个虚拟调用解析回该功能的具体类型。对 Visit 方法的调用不是虚拟的——对 visitor.Visit(this) 的调用调用了正确的重载，因为此时它知道被访问对象的确切静态类型。不保留类型转换和类型安全。

当添加新的访问者类型时，这种模式非常有用。当元素(在您的情况下为特征)发生变化时会更加痛苦 - 每次添加新元素时，您都需要更新 IVisitor 接口(interface)和所有实现。所以慎重考虑。

正如我提到的，这本书出版已经快 20 年了，因此您可以在那里找到许多关于访问者模式的分析和改进。有益的是，这为您提供了足够的起点来继续您的分析。