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

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

我正在使用 C# 工作。

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

到目前为止我有一个IFeature接口，以及实现它的一些功能类型：ChartFeature, ListFeature， ETC。 我读取了从数据库启用的功能列表，并将每个功能与数据 id 一起传递给一个方法，该方法返回一个填充的IFeature正确的类型。

我也有一个IReportWriter接口TextReportWriter和 PdfReportWriter 实现。该接口有一个方法：AddFeature(IFeature).

问题是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。

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

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

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

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

基本思想是，您有两个一般事物 - 您有元素（即您正在处理的事物）和访问者，它们对元素进行处理。您需要对它们进行动态分派 - 因此调用的实际方法会根据元素和访问者的具体类型而有所不同。

在 C# 中，有点像您的示例，您可以定义一个 IFeatureVisitor 接口，如下所示：

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

然后，在 IFeature 界面中添加“Accept”方法。

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

您的功能实现将实现 Accept 方法，如下所示：

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

然后，您的报告编写者将实现 IVisitor 接口并执行每种类型中应执行的操作。

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

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

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

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

正如我提到的，这本书出版已经快 20 年了，所以你可以在书中找到很多关于 Visitor 模式的分析和改进。很有帮助的是，这为您提供了足够的开始来继续您的分析。