使用泛型的复杂继承

Question

假设我有一组类/接口：

class ObjectData { }
class UnitData : ObjectData { }
class Component1Data : UnitData { }
class Component2Data : UnitData { }

interface IObject { }
interface IUnit : IObject { }
interface IComponent1 : IUnit { }
interface IComponent2 : IUnit { }

abstract class Object<D, O, I>
    where D : ObjectData
    where O : Object<D, O, I>, I, new()
    where I : IObject
{ }

这里的主要兴趣点是Object 类，它是某些层次结构中的基本泛型类。类型参数“O”是一种指定从Object 派生的实际类的类型的方法。因此，可以在没有问题的情况下声明和编译这样的内容：

class Unit : Object<UnitData, Unit, IUnit>, IUnit { }

但我想做的是定义另一个从 Object 派生的通用“第二级”类，它也应该作为几个类似“第三级”实体的基类。它必须是非抽象的，因为它也是某种实体。所以我需要定义这样的东西：

class Unit<D, I> : Object<D, Unit<D, I>, I>, IUnit
    where D : UnitData
    where I : IUnit
{ }

class Component1 : Unit<Component1Data, IComponent1>, IComponent1 { }
class Component2 : Unit<Component2Data, IComponent2>, IComponent2 { }

它会产生以下编译错误：

error CS0311: The type 'Unit<D, I>' cannot be used as type parameter 'O' in the generic type or method 'Object<D, O, I>'. There is no implicit reference conversion from 'Unit<D, I>' to 'I'.

问题是为什么？在我看来，如果Unit<D, I> 正在实现IUnit，并且参数“I”被指定为where I : IUnit，那么一切都应该没问题。我就是这么看的。我没看到什么？

Answer 1

简化问题；

interface IObject { }
interface IUnit : IObject { }
interface IFoo : IUnit { }

abstract class Object<O, I>
    where O : Object<O, I>, I, new()
    where I : IObject
{}

class Unit : Object<Unit, IUnit>, IUnit
{
}

这很高兴并且可以编译。我在这里用IUnit 替换了I。现在换成更衍生的东西：

class Unit : Object<Unit, IFoo>, IUnit

你得到错误：

类型“Unit”不能用作泛型中的类型参数“O” 类型或方法“对象”。没有隐式引用 从“单位”转换为“IFoo”。

所以... Unit，派生自 IUnit 不能转换为 IFoo，即使两者都实现 IUnit... 因为 Unit 不派生自 IFoo...是对象的一个​​条件：

where O : Object<O, I>, I`

这要求你做一些你不被允许做的事情：

class Unit<I> : Object<Unit<I>, I>, I

Answer 2

就像其他人评论的那样，您的泛型太复杂了。 至少，在我看来，不需要I 类型参数，因为您的Objects 将实现相应的接口。

所以，代码可以这样简化：

abstract class Object<D, O> : IObject
    where D : ObjectData
    where O : Object<D, O>
{
}

class Unit<D> : Object<D, Unit<D>>, IUnit
    where D : UnitData
{
}

在没有完全理解的情况下，O在Objects层次结构内部是如何使用的，很难说，是不是可以扔掉O类型参数。

您提到了静态工厂方法 - 这绝对不是带来如此复杂性的原因。但是，当然，您更了解用例。