为什么泛型类型约束不可继承/分层强制

Question

项目类

public class Item
{
    public bool Check(int value) { ... }
}

具有泛型类型约束的基抽象类

public abstract class ClassBase<TItem>
    where TItem : Item
{
    protected IList<TItem> items;

    public ClassBase(IEnumerable<TItem> items)
    {
        this.items = items.ToList();
    }    

    public abstract bool CheckAll(int value);
}

没有约束的继承类

public class MyClass<TItem> : ClassBase<TItem>
{
    public override bool CheckAll(int value)
    {
        bool result = true;
        foreach(TItem item in this.items)
        {
            if (!item.Check(value)) // this doesn't work
            {
                result = false;
                break;
            }
        }
        return result;
    }
}

我想知道为什么泛型类型约束不可继承？因为如果我的继承类继承自基类并传递对基类有约束的泛型类型，那么它自动意味着继承类中的泛型类型应该具有相同的约束，而无需显式定义它。不应该吗？

我是否做错了什么，理解错误，或者泛型类型约束真的不可继承吗？如果后者是真的，到底为什么会这样？

一些额外的解释

为什么我认为在类上定义的泛型类型约束应该在子类上继承或强制执行？让我给你一些额外的代码，让它不那么明显。

假设我们拥有上述所有三个类。然后我们还有这个类：

public class DanteItem
{
    public string ConvertHellLevel(int value) { ... }
}

正如我们所看到的，这个类不是从 Item 继承的，因此它不能用作 ClassBase 那样的具体类（忘记事实上，ClassBase 目前是抽象的，它也可以是一个常规类）。由于 MyClass 没有为其泛型类型定义任何约束，因此拥有 MyClass 似乎完全有效...

但是。这就是为什么我认为泛型类型约束应该像成员泛型类型约束一样在继承的类上继承/强制执行，因为如果我们查看 MyClass 的定义，它会说：

MyClass<T> : ClassBase<T>

当 T是 DanteItem 我们可以看到它自动不能与 MyClass 一起使用，因为它继承自 ClassBase 和 DanteItem< /code> 未满足其要求泛型类型约束。我可以说 MyClass 上的 **泛型类型取决于 ClassBase 泛型类型约束，因为否则 MyClass 可以用任何类型实例化。但我们知道不可能。

时，情况当然会有所不同

public class MyClass<T> : ClassBase<Item>

当我将 MyClass 定义为：在这种情况下，T 与基类的泛型类型没有任何关系，因此它独立于基类

。这是一个有点长的解释/推理。我可以简单地总结一下：

如果我们不对 MyClass 提供泛型类型约束，则隐式意味着我们可以使用任何具体类型实例化 MyClass。但我们知道这是不可能的，因为 MyClass 是从 ClassBase 继承的，并且具有泛型类型约束。

我希望现在这更有意义。

Answer 1

另一个更新：

这个问题是我博客的主题2013 年 7 月。感谢您提出的好问题！

更新：

我对此进行了更多思考，我认为问题是您根本不需要继承。相反，您想要的是必须放置在类型参数上的所有约束，以便该类型参数用作另一种类型中的类型参数，以自动推导并以不可见的方式添加到类型参数的声明中. 是吗？

一些简化的示例：

class B<T> where T:C {}
class D<U> : B<U> {}

U 是一个类型参数，在必须是 C 的上下文中使用。因此，您认为编译器应该推断出这一点，并自动对 U 施加 C 的约束。

这个怎么样？

class B<T, U> where T : X where U : Y {}
class D<V> : B<V, V> {}

现在 V 是在必须同时是 X 和 Y 的上下文中使用的类型参数。因此，您认为编译器应该推断出这一点，并自动对 V 施加 X 和 Y 的约束。是吗？

这又如何呢？

class B<T> where T : C<T> {}
class C<U> : B<D<U>> where U : IY<C<U>> {}
class D<V> : C<B<V>> where V : IZ<V> {}

这是我编造的，但我向你保证这是一个完全合法的类型层次结构。请描述一个清晰一致的规则，该规则不会进入无限循环来确定 T、U 和 V 上的所有约束。不要忘记处理已知类型参数是引用类型并且接口约束具有的情况协变或逆变注释！此外，该算法必须具有这样的属性：无论 B、C 和 D 在源代码中出现的顺序如何，它都会给出完全相同相同的结果。

如果约束推断是您想要的功能，那么编译器必须能够处理此类情况，并在无法处理时给出明确的错误消息。

基本类型有什么特别之处？为什么不实际完全实现该功能呢？

class B<T> where T : X {}
class D<V> { B<V> bv; }

V 是在必须可转换为 X 的上下文中使用的类型参数；因此编译器应该推断出这个事实并对 V 施加 X 的约束。是吗？或者没有？

为什么领域很特殊？怎么样：

class B<T> { static public void M<U>(ref U u) where U : T {} }
class D<V> : B<int> { static V v; static public void Q() { M(ref v); } }

V 是一个类型参数，在只能是 int 的上下文中使用。因此，C# 编译器应该推断出这一事实并自动对 V 施加 int 约束。

是吗？不？

你知道这是怎么回事吗？它在哪里停止？为了正确实现您想要的功能，编译器必须进行整个程序分析。

编译器不会进行这种级别的分析，因为这是本末倒置。当您构造泛型时，您需要向编译器证明您已满足约束。编译器的工作不是弄清楚你想说什么并找出哪些进一步的约束集满足原始约束。

出于类似的原因，编译器也不会尝试代表您自动推断接口中的方差注释。有关详细信息，请参阅我关于该主题的文章。

http://blogs.msdn.com/b/ericlippert/archive/2007/10/29/covariance-and-contravariance-in-c-part-7-why-do-we-need- a-syntax-at-all.aspx

---

原答案：

我想知道为什么泛型类型约束不可继承？

只有成员被继承。约束不是成员。

如果我的继承类继承自基类并传递对基类有约束的泛型类型，那么它自动意味着继承类中的泛型类型应该具有相同的约束，而无需显式定义它。不应该吗？

您只是断言某件事应该如何，而没有提供任何解释为什么它应该是这样。向我们解释一下为什么你相信世界应该是这样的； 好处是什么，缺点是什么，以及成本是什么？

我做错了什么，理解错误还是泛型类型约束真的不可继承？

通用约束不会被继承。

如果后者是真的，那到底是为什么呢？

默认情况下，功能“未实现”。我们不必提供某个功能未实现的原因！ 每个功能只有在有人花钱来实现时才会实现。

现在，我急于指出，泛型类型约束是在方法上继承的。方法是成员，成员是继承的，约束是方法的一部分（尽管不是其签名的一部分）。因此，在继承方法时，约束也随之而来。当您说：

class B<T> 
{
    public virtual void M<U>() where U : T {}
}

class D<V> : B<IEnumerable<V>>
{
    public override void M<U>() {}
}

那么 D.M 继承约束并用 IEnumerable 替换 T；因此，约束条件是 U 必须可转换为 IEnumerable。请注意，C# 不允许您重新声明约束。我认为这是一个错误。为了清楚起见，我希望能够重申这一限制。

但 D 并没有从 B 继承对 T 的任何类型的约束；我不明白这怎么可能。 M 是 B 的成员，并且由 D 及其约束继承。但T本来就不是B的成员，那有什么可继承的呢？

我真的完全不明白你想要什么功能。你能解释得更详细吗？

Answer 2

下面是一种场景，其中此行为的隐式性质会导致与预期不同的行为：

我认识到此场景在设置量方面可能显得过多，但这只是此行为可能导致问题的一个示例。软件应用程序可能很复杂，因此即使这种情况看起来很复杂，我也不认为这种情况不会发生。

在此示例中，有一个 Operator 类实现了两个类似的接口：IMonitor 和 IProcessor。两者都有一个 start 方法和一个 IsStarted 属性，但 Operator 类中每个接口的行为是独立的。即，Operator 类中有一个 _MonitorStarted 变量和一个 _ProcessorStarted 变量。

MyClass 派生自 ClassBase。 ClassBase 对 T 有一个类型约束，它必须实现 IProcessor 接口，并且根据建议的行为 MyClass 继承该类型约束。

MyClass 有一个 Check 方法，该方法是在假设可以从内部 IProcessor 对象获取 IProcessor.IsStarted 属性的值的情况下构建的。

假设有人更改了 ClassBase 的实现，以删除 IProcessor 对泛型参数 T 的类型约束，并将其替换为 IMonitor 的类型约束。该代码将默默地工作，但会产生不同的行为。原因是 MyClass 中的 Check 方法现在调用 IMonitor.IsStarted 属性而不是 IProcessor.IsStarted 属性，即使 MyClass 的代码> 完全没有改变。

public interface IMonitor
{
    void Start();

    bool IsStarted { get; }
}

public interface IProcessor
{
    void Start();

    bool IsStarted { get; }
}

public class Operator : IMonitor, IProcessor
{
    #region IMonitor Members

    bool _MonitorStarted;

    void IMonitor.Start()
    {
        Console.WriteLine("IMonitor.Start");
        _MonitorStarted = true;
    }

    bool IMonitor.IsStarted
    {
        get { return _MonitorStarted; }
    }

    #endregion

    #region IProcessor Members

    bool _ProcessorStarted;

    void IProcessor.Start()
    {
        Console.WriteLine("IProcessor.Start");
        _ProcessorStarted = true;
    }

    bool IProcessor.IsStarted
    {
        get { return _ProcessorStarted; }
    }

    #endregion
}

public class ClassBase<T>
    where T : IProcessor
{
    protected T Inner { get; private set; }

    public ClassBase(T inner)
    {
        this.Inner = inner;
    }

    public void Start()
    {
        this.Inner.Start();
    }
}

public class MyClass<T> : ClassBase<T>
    //where T : IProcessor
{
    public MyClass(T inner) : base(inner) { }

    public bool Check()
    {
        // this code was written assuming that it is calling IProcessor.IsStarted
        return this.Inner.IsStarted;
    }
}

public static class Extensions
{
    public static void StartMonitoring(this IMonitor monitor)
    {
        monitor.Start();
    }

    public static void StartProcessing(this IProcessor processor)
    {
        processor.Start();
    }

}

class Program
{
    static void Main(string[] args)
    {
        var @operator = new Operator();

        @operator.StartMonitoring();

        var myClass = new MyClass<Operator>(@operator);

        var result = myClass.Check();

        // the value of result will be false if the type constraint on T in ClassBase<T> is where T : IProcessor
        // the value of result will be true if the type constraint on T in ClassBase<T> is where T : IMonitor
    }
}

Answer 3

我认为您很困惑，因为您也在使用 TItem 声明派生类。

如果你想一想，如果你使用 Q 来代替的话。

public class MyClass<Q> : BaseClass<Q>
{
 ...
}

那么如何判断Q是item类型呢？

您还需要将约束添加到派生类 Generic Type 中，以便

public class MyClass<Q> : BaseClass<Q> were Q : Item { ... } 

Answer 4

因为 ClassBase 对他的模板有一个约束（应该是 typeof Item），所以你也必须将这个约束添加到 MyClass 中。
如果不这样做，您可以创建 MyClass 的新实例，其中模板不是 Item 类型。创建基类时，会失败。

[编辑]
嗯，现在重新阅读您的问题，我看到您的代码可以编译吗？好的。

好吧，在 MyClass 中，您不知道 this.items 的基类型，因此无法调用 Check 方法。
this.items 是 IList 类型，并且在您的类中，未指定 TItem，这就是该类不理解 Check 方法的原因。

让我反驳你的问题，为什么你不想将约束添加到你的 MyClass 类中？将任何其他类类型作为此类的模板，都会导致错误。为什么不通过添加约束来防止此错误，这样编译时就会失败。