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

Question

关于泛型类型约束的局限性，我有一个非常常见的场景，需要定义另一个泛型。

已经讨论过(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;
        }
    }
}

这很好，我们仍然有一些变通方法，可以通过使用接口(interface)或构建新的基类，如下所示:

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)
    {
    }
}

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

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

是的，这些会让你发疯(例如递归约束)并让你抓狂……但在某些情况下这仍然很方便，特别是在类型安全方面。

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

Answer 1

这对你有用吗？

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

}

它不如类型构造函数强大，因为 T在Property<T>不能变化，但看起来您并不是在寻找那种灵 active 。