Question

我有一个非常常见的场景，关于通用类型约束的限制，需要定义另一个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>
{

}

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

Answer 2

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

如果您明确需要对type参数执行某些操作，我只会担心设置相当复杂的类型约束。比如说，你需要来保证它是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界面，因为反对和共同变量可能只能在类接口而不是它的实现上定义

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

2 个答案: