通用约束——我不确定如何用非此即彼的情况来解决这种情况答案

【问题标题】：Generic constraints -- I'm not sure how to fix this situation with an either/or case通用约束——我不确定如何用非此即彼的情况来解决这种情况
【发布时间】：2012-02-18 12:50:22
【问题描述】：

基本上我有以下几点：

public static bool IsBetween<T>(this T value, T a, T b)
    where T : IComparable
{
    ...
}

public static bool IsBetween<T>(this T value, T a, T b)
    where T : IComparable<T>
{
    ...
}

问题是我不能这样做，因为即使约束不同，您也不能拥有具有相同签名的成员。但是，无法声明约束是IComparable 或IComparable<T>。所以，我不确定除了挑选一个并继续使用它之外还能做什么。而且，无论我选择哪一个，我都会输掉另一个，因为它们是独立的并且不会相互继承（这是有道理的）。

我在这里遗漏了什么，有办法同时使用两者，还是我必须选择一个（可能是通用版本）？

【问题讨论】：

标签： c# generics extension-methods icomparable generic-constraints

【解决方案1】：

我不明白为什么第一种方法是通用的。为什么不只是：

public static bool IsBetween(this IComparable value, IComparable left, IComparable right)

使方法泛型增加了什么价值？显然，您不会避免装箱惩罚，因为当您调用 CompareTo(object) 时，值将被装箱。

除非您有令人信服的理由使该方法具有通用性，否则不要使其通用。然后它具有与其他方法不同的签名，您的问题就解决了。

【讨论】：

我从来没有这样想过。我想这是因为我从通用版本开始，然后复制/粘贴它并尝试快速更改。
另外，默认情况下会先选择IComparable<T> 选项，然后再选择IComparable 选项吗？
@m-y：重载解析会选择更具体的方法。如果无法确定哪个更具体，则会出现歧义错误。

【解决方案2】：

在 .NET 中，方法解析重载不考虑返回类型和泛型约束。因此，即使 IComparable 和 IComparable<T> 有一些共同点，但仍然无法正常工作。只需选择IComparable<T> 版本。标准 .NET 类型（例如 Int32、Decimal、DateTime 等）无论如何都实现了这两个接口。

【讨论】：

这就是我的想法，但我想确保我没有遗漏任何东西。我最终将使用通用版本。我只是希望我的方法可用于仅实现 IComparable 而不是两者（或仅实现 IComparable<T>）的其他代码。