编写解析器时，返回多类型对象的方法的替代实现方案咨询

这确实是静态类型语言里处理动态返回类型时的典型痛点，除了object和dynamic，还有几个更优的方案可以考虑，各有适用场景，下面逐一拆解：

1. 自定义结果容器类/结构体 #

创建一个专门的类型来封装所有可能的返回值，同时附带一个类型标识枚举，让调用者能明确判断当前结果的类型。这种方案完全避免装箱拆箱，且类型安全。

实现示例： #

首先定义类型标识枚举：

public enum ExpressionResultType
{
    String,
    Int,
    Version,
    DateTime
}

然后创建结果结构体（用结构体比类更节省堆分配开销）：

public readonly struct ExpressionEvaluationResult
{
    public ExpressionResultType Type { get; }
    public string? StringValue { get; }
    public int? IntValue { get; }
    public Version? VersionValue { get; }
    public DateTime? DateTimeValue { get; }

    private ExpressionEvaluationResult(ExpressionResultType type, string? str, int? i, Version? v, DateTime? dt)
    {
        Type = type;
        StringValue = str;
        IntValue = i;
        VersionValue = v;
        DateTimeValue = dt;
    }

    // 提供便捷的创建方法
    public static ExpressionEvaluationResult FromString(string value) => 
        new(ExpressionResultType.String, value, null, null, null);
    
    public static ExpressionEvaluationResult FromInt(int value) => 
        new(ExpressionResultType.Int, null, value, null, null);
    
    public static ExpressionEvaluationResult FromVersion(Version value) => 
        new(ExpressionResultType.Version, null, null, value, null);
    
    public static ExpressionEvaluationResult FromDateTime(DateTime value) => 
        new(ExpressionResultType.DateTime, null, null, null, value);
}

修改你的求值方法：

private ExpressionEvaluationResult EvaluateExpression(Expression expression)
{
    // 示例：假设求值后得到一个int结果
    if (expression is IntExpression intExpr)
    {
        return ExpressionEvaluationResult.FromInt(intExpr.Value);
    }
    // 其他表达式类型的处理逻辑...
}

优势： #

• 零装箱拆箱，性能最优
• 类型安全，编译时就能避免错误的类型转换
• 调用者通过Type属性可以清晰判断结果类型

劣势： #

• 需要维护容器类型的扩展（如果后续新增返回类型，要同步修改枚举和容器）

2. 访问者模式（Visitor Pattern） #

如果你的Expression本身是树形结构（比如包含不同类型的表达式节点），访问者模式是非常优雅的解决方案。它把结果的处理逻辑从求值方法中分离出来，完全不需要返回值，而是通过访问者接口的回调来处理不同类型的结果。

实现示例： #

首先定义访问者接口：

public interface IExpressionResultVisitor
{
    void VisitStringResult(string value);
    void VisitIntResult(int value);
    void VisitVersionResult(Version value);
    void VisitDateTimeResult(DateTime value);
}

修改求值方法，接收访问者作为参数：

private void EvaluateExpression(Expression expression, IExpressionResultVisitor visitor)
{
    // 示例：求值得到字符串结果，调用对应的访问方法
    if (expression is StringExpression strExpr)
    {
        visitor.VisitStringResult(strExpr.Value);
        return;
    }
    // 其他表达式类型的处理逻辑...
}

使用时，实现访问者来处理结果：

public class ResultProcessor : IExpressionResultVisitor
{
    public void VisitStringResult(string value)
    {
        // 处理字符串结果的逻辑
        Console.WriteLine($"Got string: {value}");
    }

    public void VisitIntResult(int value)
    {
        // 处理int结果的逻辑
        Console.WriteLine($"Got int: {value}");
    }

    // 实现剩余的访问方法...
}

优势： #

• 完全消除装箱拆箱，性能优异
• 遵循单一职责原则，求值逻辑和结果处理逻辑分离
• 扩展性好：新增返回类型时，只需要扩展访问者接口和实现类，不需要修改求值方法

劣势： #

• 初期需要设计访问者结构，有一定的代码量开销
• 适合表达式结构复杂的场景，简单场景可能有点“重”

3. 带类型标识的元组 #

如果不想写额外的类/结构体，可以用值元组返回类型标识和结果，虽然还是有装箱（除了值类型），但比单纯返回object更安全，调用者能明确知道结果类型，减少转换错误。

实现示例： #

private (ExpressionResultType Type, object Value) EvaluateExpression(Expression expression)
{
    // 示例：返回int类型结果
    return (ExpressionResultType.Int, 42);
}

调用时：

var result = EvaluateExpression(expr);
if (result.Type == ExpressionResultType.Int)
{
    var intValue = (int)result.Value;
    // 处理逻辑
}

优势： #

• 代码改动最小，不需要新增类型
• 比单纯返回object更安全，类型标识避免盲目转换

劣势： #

• 依然存在装箱拆箱（值类型转object时）
• 类型安全不如容器类和访问者模式

方案选择建议 #

• 如果你的表达式结构复杂，且后续可能扩展更多返回类型：优先选访问者模式
• 如果表达式结构简单，追求最高性能：优先选自定义结果结构体
• 如果只是临时过渡，不想写太多代码：可以用带类型标识的元组

dynamic的性能开销确实比装箱拆箱高，除非是极端简单的场景，否则不推荐；单纯的object返回则容易出现类型转换错误，也不建议长期使用。

内容的提问来源于stack exchange，提问作者cogumel0