3

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

已经讨论过（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)
    {
    }
}

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

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

是的，那些可能会让你非常疯狂（例如递归约束）并让你把你的头发拉出来......但仍然有一些情况可以方便，特别是在类型安全方面。

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

4

2 回答 2

1

我以前在尝试用 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 接口，因为逆变和协变可能只能在类接口上定义，而不是它的实现

于 2015-08-23T10:58:47.623 回答
1

这对你有用吗？

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

}

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

于 2015-08-23T10:57:08.947 回答