自反型参数约束：X 其中T：X – 任何更简单的替代方案？

我经常通过向其添加自引用（“反身”）类型参数约束来使简单的界面更复杂。 例如，我可能会这样做：

interface ICloneable { ICloneable Clone(); } class Sheep : ICloneable { ICloneable Clone() { … } } //^^^^^^^^^^ Sheep dolly = new Sheep().Clone() as Sheep; //^^^^^^^^ 

成：

 interface ICloneable where TImpl : ICloneable { TImpl Clone(); } class Sheep : ICloneable { Sheep Clone() { … } } //^^^^^ Sheep dolly = new Sheep().Clone(); 

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

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

问：有没有人知道另一种C＃代码模式可以实现相同的效果或类似的东西，但是更容易掌握？

---

_{*）此代码模式可能不直观且难以理解，例如以下方式：}

• _{声明X where T : X似乎是递归的，有人可能想知道为什么编译器不会卡在无限循环中 ，推理， “如果T是X ，那么X实际上是X<X<……>> 。“ （但是限制显然不会像那样得到解决。）}

• _{对于实现者来说，代替TImpl应该指定什么类型可能并不明显。 （约束最终会解决这个问题。）}

• _{一旦你在混合中添加更多类型参数和各种通用接口之间的子类型关系，事情就会很快变得无法管理。}

Answer 1

主要优点：实现类型现在可以引用自身而不是基类型，从而减少了对类型转换的需求

虽然看起来似乎是通过引用自身的类型约束，它强制实现类型执行相同的操作，但实际上并不是它的function。 人们使用这种模式来尝试表达forms的模式“这种方法的覆盖必须返回覆盖类的类型”，但实际上并不是类型系统表达或强制执行的约束。 我在这里举个例子：

http://blogs.msdn.com/b/ericlippert/archive/2011/02/03/curiouser-and-curiouser.aspx

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

是的。 我尽量避免这种模式。 这很难说。

有没有人知道另一种C＃代码模式可以实现相同的效果或类似的东西，但是更容易掌握？

不是在C＃中，没有。 如果这种事情让你感兴趣，你可以考虑看一下Haskell类型系统; Haskell的“更高类型”可以代表那种类型的模式。

声明X where T : X似乎是递归的，有人可能想知道为什么编译器不会卡在无限循环中，推理，“如果T是X ，那么X实际上是X…>> 。“

在推理这种简单关系时，编译器不会进入无限循环。 然而， 具有逆变的通用类型的名义子类型通常是不可靠的 。 有一些方法可以强制编译器进行无限回归，而C＃编译器在开始无限旅程之前不会检测到这些并阻止它们。 （然而。我希望在Roslyn编译器中为此添加检测，但我们会看到。）

如果您对此感兴趣，请参阅我关于该主题的文章。 你也想阅读链接到论文。

http://blogs.msdn.com/b/ericlippert/archive/2008/05/07/covariance-and-contravariance-part-twelve-to-infinity-but-not-beyond.aspx

Answer 2

不幸的是，没有办法完全防止这种情况，并且没有类型约束的通用ICloneable就足够了。 您的约束仅将可能的参数限制为自己实现它的类，这并不意味着它们是当前正在实现的类。

换句话说，如果一个Cow实现了ICloneable ，你仍然可以轻松地让Sheep实现ICloneable 。

我会简单地使用ICloneable而没有约束，原因有两个：

1. 我严重怀疑你会错误地使用错误的类型参数。

2. 接口意味着是代码的其他部分的合同 ，而不是用于在自动驾驶仪上编码。 如果代码的一部分需要ICloneable并且你传递了一个可以做到这一点的Sheep ，那么从那一点看它似乎是完全有效的。