c# -类型约束和限制，任何保持类型安全的变通方法

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

这已经被讨论过了(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)
    {
    }
}

这时候，人们通常会说不，设计不应该那么复杂……回顾你的业务需求，使用大量的接口和组合，继承不仅仅是为了节省你写一些额外的代码，这些类应该形成某种类型的家族，好吧，它们确实形成了一种家族。

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

是的，这些可以让你发疯(例如递归约束)，让你拔头发…但是在某些情况下，这还是很方便的，特别是在涉及类型安全的情况下。

无论如何，关于这些约束是什么是最合适的，一般的指导方针，遵循回到轨道，任何其他的解决方案，而不是仅仅使用接口或在构造函数中选择类型子集?

这对你有用吗?

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

它不如类型构造函数强大，因为Property<T>中的T不能变化，但无论如何，您似乎都没有在寻找那种灵活性。

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

相关内容

最新更新

热门标签：