C# - 类型约束和限制，保持类型安全的任何解决方法？

Question

关于 Generic Type Constraint 的限制，我有一个非常常见的场景，需要定义另一个 Generic。

已经讨论过（Eric Lippert 本人和其他人），但到目前为止，我还没有看到一般指导方针，或者说在遇到以下情况时可以应用的经验法则：

public abstract class Class<TProperty> : Class
     where TProperty : Property<>
// Sadly the line above cannot work, although the compiler could actually infer
// the Generic Type, since defining two class definitions like:
// Considering A & B two other well-defined classes
// Class<TA> where TA : A and 
// Class<TB> where TB : B is not allowed and well-understandable
{
    protected Class(TProperty property)
    {
        if (property != null)
        {
            this._property = property;
        }
        else
        {
            throw new ArgumentNullException(@"property");
        }
    }

    private readonly TProperty _property;
    public TProperty Property
    {
        get
        {
            return this._property;
        }
    }
}
public abstract class Property<TParentClass>
// Same remark goes here
    where TParentClass : Class<>
{
    protected Property(TParentClass parent)
    {
        if (parent != null)
        {
            this._parent = parent;
        }
        else
        {
            throw new ArgumentNullException(@"parent");
        }
    }

    private readonly TParentClass _parent;
    internal TParentClass Parent
    {
        get
        {
            return this._parent;
        }
    }
}

这很好，我们仍然有一些解决方法，方法是使用接口或构建新的基类，如下所示：

public abstract class Class
{
}
public abstract class Class<TProperty> : Class
    where TProperty : Property
{
    protected Class(TProperty property)
    {
        if (property != null)
        {
            this._property = property;
        }
        else
        {
            throw new ArgumentNullException(@"property");
        }
    }

    private readonly TProperty _property;
    public TProperty Property
    {
        get
        {
            return this._property;
        }
    }
}

public abstract class Property
{
}
public abstract class Property<TParentClass>
    where TParentClass : Class
{
    protected Property(TParentClass parent)
    {
        if (parent != null)
        {
            this._parent = parent;
        }
        else
        {
            throw new ArgumentNullException(@"parent");
        }
    }

    private readonly TParentClass _parent;
    internal TParentClass Parent
    {
        get
        {
            return this._parent;
        }
    }
}

这很好，但如果我想添加一个新的合法继承层会发生什么？

public abstract class InheritedClass<TInheritedProperty> : Class<TInheritedProperty>
// Damn it! I wanted to be more specific but I cannot have <> (and also <,>, <,,>, etc.)
// Cannot do that without declaring another public interface... sad
// Or another non generic base class
    where TInheritedProperty : Property
{
    // But this remark cannot work here... I would have needed a "real" type not InheritedProperty<>...
    // Yeah this is it: starting to bake the noodles
    protected InheritedClass(TInheritedProperty property)
        : base(property)
    {
    }
}

public abstract class InheritedProperty<TInheritedClass> : Property<TInheritedClass>
// Same goes here
    where TInheritedClass : Class
{
    protected InheritedProperty(TInheritedClass parent)
        : base(parent)
    {
    }
}

甚至更糟（代码显然无法编译）并且在没有真正的类型安全的情况下变得非常愚蠢：

public abstract class InheritedClass2<TInheritedProperty, TInheritedPropertyClass> : Class<TInheritedProperty>
    where TInheritedProperty : InheritedProperty2<TInheritedPropertyClass, TInheritedProperty>
{
    protected InheritedClass2(TInheritedProperty property)
        : base(property)
    {
    }
}

public abstract class InheritedProperty2<TInheritedClass, TInheritedClassProperty> : Property<TInheritedClass>
    where TInheritedClass : InheritedClass2<TInheritedClassProperty, TInheritedClass>
{
    protected InheritedProperty2(TInheritedClass parent)
        : base(parent)
    {
    }
}

那时人们通常会说不，设计不应该那么复杂......检查您的业务需求并使用组合的大量接口，继承不仅可以节省您编写一些额外的代码，这些类应该组成某种家庭，好吧，他们确实组成了一个家庭。

好吧，这很公平，但这并不能真正解决我不得不承认被过度夸大的情况，但在某些情况下，具有约束的继承是有意义的，并且这些约束也具有约束。

是的，那些可能会让你发疯（例如递归约束）并让你大发雷霆……但在某些情况下这仍然很方便，尤其是在类型安全方面。

无论如何，关于这些约束，最适合遵循的一般准则是什么，以重新回到正轨，除了使用接口或在构造函数中选择类型子集之外，还有其他解决方案吗？

Answer 1

这对你有用吗？

public abstract class Class<TProperty, T>
   where TProperty : Property<T>
{

}

它不如类型构造函数强大，因为Property<T> 中的T 不能变化，但看起来你似乎并不在寻找那种灵活性。

Answer 2

我之前在尝试用 C# 对一个相当复杂的应用程序模型进行超模板化时遇到过类似的问题。我得出的结论是编译器只能做这么多。

如果您特别需要对类型参数做某事，我只会担心设置相当复杂的类型约束。例如，您需要保证它是IEnumerable，因为您的Class 将对其进行迭代。在这些示例中，您根本不需要类型约束。

但是，如果您发现自己迫切需要维护类型约束，您可以尝试利用逆方差和协方差来约束子类型，如下所示：

class Foo<TProperty> : Class
    where TProperty : IProperty<object>
{
    // Same as your implementation
}

interface IProperty<out T>
{
    T Property;
}

class Property<T> : IProperty
{
    // Same as your implementation
}

编辑：添加了 IProperty 接口，因为逆变和协变可能只能在类接口上定义，而不是它的实现