自反类型参数约束：X其中T：X T 。 ‒有更简单的替代方案吗？

发布于 2024-12-27 04:51:58 字数 1373 浏览 2 评论 0 原文

我经常通过向简单的接口添加自引用（“自反”）类型参数约束来使简单的接口变得更加复杂。例如，我可以将其转换

interface ICloneable
{
    ICloneable Clone();
}

class Sheep : ICloneable
{
    ICloneable Clone() { … }
} //^^^^^^^^^^

Sheep dolly = new Sheep().Clone() as Sheep;
                                //^^^^^^^^

为：

interface ICloneable<TImpl> where TImpl : ICloneable<TImpl>
{
    TImpl Clone();
}

class Sheep : ICloneable<Sheep>
{
    Sheep Clone() { … }
} //^^^^^

Sheep dolly = new Sheep().Clone();

主要优点：实现类型（例如 Sheep）现在可以引用自身而不是其基本类型，从而减少了类型转换的需要（如最后一行代码）。

虽然这非常好，但我也注意到这些类型参数约束并不直观，并且在更复杂的场景中往往变得非常难以理解。^*)

问题：有谁知道另一种 C# 代码模式可以实现相同的效果或类似的效果，但更容易掌握？

_{*) 这种代码模式可能不直观且难以理解，例如通过以下方式：}

_{声明X；其中 T : X 似乎是递归的，人们可能想知道为什么编译器不会卡住在无限循环中，推理，“如果 T 是 X，则 X真的是X...>>。”（但约束显然不会像这样得到解决。）}
< /里>
_{对于实现者来说，应该指定什么类型来代替 TImpl 可能并不明显。（约束最终会解决这个问题。）}

_{一旦添加更多类型参数以及各种泛型接口之间的子类型关系，事情很快就会变得难以管理。}

原文

Every so often I am making a simple interface more complicated by adding a self-referencing ("reflexive") type parameter constraint to it. For example, I might turn this:

interface ICloneable
{
    ICloneable Clone();
}

class Sheep : ICloneable
{
    ICloneable Clone() { … }
} //^^^^^^^^^^

Sheep dolly = new Sheep().Clone() as Sheep;
                                //^^^^^^^^

into:

interface ICloneable<TImpl> where TImpl : ICloneable<TImpl>
{
    TImpl Clone();
}

class Sheep : ICloneable<Sheep>
{
    Sheep Clone() { … }
} //^^^^^

Sheep dolly = new Sheep().Clone();

Main advantage: An implementing type (such as Sheep) can now refer to itself instead of its base type, reducing the need for type-casting (as demonstrated by the last line of code).

While this is very nice, I've also noticed that these type parameter constraints are not intuitive and have the tendency to become really difficult to comprehend in more complex scenarios.^*)

Question: Does anyone know of another C# code pattern that achieves the same effect or something similar, but in an easier-to-grasp fashion?

_{*) This code pattern can be unintuitive and hard to understand e.g. in these ways:}

_{The declaration X<T> where T : X<T> appears to be recursive, and one might wonder why the compiler doesn't get stuck in an infinite loop, reasoning, "If T is an X<T>, then X<T> is really an X<X<…<T>…>>." (But constraints obviously don't get resolved like that.)}

_{For implementers, it might not be obvious what type should be specified in place of TImpl. (The constraint will eventually take care of that.)}

_{Once you add more type parameters and subtyping relationships between various generic interfaces to the mix, things get unmanageable fairly quickly.}