关于泛型类型约束的限制,我有一个非常常见的场景,需要定义另一个泛型。
已经讨论过(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)
{
}
}
那时人们通常会说不,设计不应该那么复杂......检查您的业务需求并使用大量接口与组合,继承不仅可以节省您编写一些额外的代码而且这些类应该形成某种形式家庭,好吧,他们确实形成了一个家庭。
好吧,很公平,但这并不能真正解决我不得不承认被过度夸大的情况,但在某些情况下,具有约束的继承是有意义的,并且这些约束也有约束。
是的,那些可能会让你非常疯狂(例如递归约束)并让你把你的头发拉出来......但仍然有一些情况可以方便,特别是在类型安全方面。
无论如何,关于这些约束,最适合遵循的一般指导方针是什么?除了使用接口或在构造函数中选择类型子集之外,还有其他解决方案吗?