类型参数“T”与外部类型的类型参数具有相同的名称 '...'

Question

public abstract class EntityBase { ... }

public interface IFoobar
{
    void Foo<T>(int x)
        where T : EntityBase, new();
}

public interface IFoobar<T>
    where T : EntityBase, new()
{
    void Foo(int x);
}

public class Foobar<T> : IFoobar, IFoobar<T>
    where T : EntityBase, new()
{
    public void Foo(int x) { ... }

    void IFoobar.Foo<T>(int x) { Foo(x); }
}

我收到编译器警告： 类型参数 'T' 与外部类型 '...' 的类型参数同名

我尝试这样做： void IFoobar.Foo(int x) { Foo(x); }，但是我不能保证 U 和 T 是相同的。 Foobar 类的实现方式非常重要，它们必须相同。

我也尝试这样做： void IFoobar.Foo(int x) where U : T { Foo(x); }，但这并不能保证 U 和 T 相等，并且不允许我重新定义约束，因为它是在接口上定义的。

Answer 1

最大的问题是您的接口定义不明确，并且与代码的意图不匹配。

如果您的 T 在界面上不公开可见，则外部代码甚至不必知道存在 T。您需要创建接收或返回 T 的方法，或者拥有一些 T 类型的属性，或者您应该完全摆脱 T ，并使您的接口成为非通用的。

一旦你支持了这一点，为什么你不需要两个不同的接口就应该变得更加明显，并且你不应该再需要协调它们。

如果事实证明您确实需要一个采用T的版本和一个非T版本，那么更惯用的方法是传递对象 而不是 T：

public interface IFoo
{
    void DoSomething(object o);
    object DoSomethingElse();
}

public interface IFoo<T>
{
    void DoSomething(T item);
    T DoSomethingElse();
}

有关示例，请参阅 IEnumerable、ICollection、IList 等接口。

但请仔细考虑。最后的设计妥协（同时具有通用版本和对象版本）总是留下一些不足之处。

您将牺牲其中之一：

• 直接传达设计契约的良好接口设计（如果您在传入错误类型时引发异常或执行无操作）
• 类型安全性，以及随之而来的错误的减少（如果您可以正确操作任何旧对象）

Answer 2

您可以执行以下两种操作之一：

1. 忽略警告并将两种类型设置为 T。

2. 执行运行时检查并引发异常：

   if (typeof(T) != typeof(U)) throw Exception("类型不同");
   

正如其他人所说，也许您需要重新考虑设计界面的方式。

Answer 3

试试吧

void IFoobar.Foo<U>(int x) { Foo(x); }

当然，这仍然不能保证 U 与 T 相同。您无法在编译时强制执行这一点，因为当您实现接口时，您必须遵循其规则——而IFoobar不会对 Foo施加这样的限制，如果这样做，您将不再实现该接口（根据定义，因为您更加严格，但您声称你不）。

您可以尝试在运行时检查它，尽管这有点“作弊”（因为您也没有真正遵守接口）。