c# - 将运行时类型(在 c# 中)用于逻辑流

Question

这个问题类似于(的一个子集)this question

在这种情况下，它使用运行时类型来区分成功和失败的返回结果。

我经常看到以下模式:

public struct Result {
    public boolean IsSuccess { get;set;}
    public string ErrorMessage {get;set;}
    public int Value {get;set;}
}
...
Result result = someObject.SomeMethod();
if (result.IsSuccess) DoSomething(result.Value);
else handleError(result.ErrorMessage);

我觉得following更自然，表达意图更明确(我认为):

public abstract class Result { }
public sealed class Failure : Result {
    public string ErrorMessage { get; set; }
}
public sealed class Success : Result {
    public int Value { get; set; }
}
...
Result result = someObject.SomeMethod();
if (result is Success) DoSomething((result as Success).Value);
else if (result is Failure) handleError((result as Failure).ErrorMessage);

另请注意，.Net(以及许多其他语言)在具有多个 catch 子句的 try-catch block 中使用此模式(其中异常类型选择一个 catch block )。

编辑:此模式(即依赖于运行时类型)与 F# 的可区分联合相同，不同之处在于在 F# 中它是原生的，而在 C# 中它是使用针对不同的结构模拟的目的。

编辑: 我认为第一个代码的主要问题是“部分初始化对象”的代码味道。在 100% 的情况下，只有一半的对象会被初始化。它还几乎违反了ISP，“几乎”是因为一旦评估了.IsSuccess，此后将仅使用对象的一部分(如果成功，则仅使用.Result，如果是错误，则仅使用错误使用属性)。运行类型检查解决方案不存在这些问题。

所以问题是:使用这种模式有什么问题？我对以下方面的问题特别感兴趣:可维护性、可读性、可测试性、概念纯度和 OOP/OOD。

Answer 1

一般来说，我更喜欢第一种形式。

第二个示例需要更多的击键并添加 4 个类型检查操作。它对消费者来说也不太明显(您不能混淆 IsSuccess 属性的含义)。仅仅为了确定操作的结果而必须执行类型转换似乎不太合逻辑(似乎类似于对程序流使用异常；您可以这样做，但您不应该这样做)。

此外，第一种形式可以作为一种独立于平台的机制来描述数据。第二个不能。换句话说，您可以轻松地序列化由基元组成的结果类型并与任何消费者共享，但需要类型检查限制/消除这种可能性。

要提高Result 对象的质量，您可以制作一个Messages 集合，它不仅包含字符串(可能包括代码、严重性、消息等)。 ).这允许您的所有结果返回消息，而不仅仅是失败的操作。如果操作失败，您可以假定 Messages 至少包含一条错误消息(和/或使用 LINQ 查询集合以查找所有与错误相关的消息)。