有没有办法创建一个无法在它的程序集之外实现的公共.NET接口？

Question

为了在.NET中保持二进制向后兼容性，通常无法向公共类和接口添加新的抽象方法。 如果这样做，那么针对扩展/实现类/接口的旧版本程序集构建的代码将在运行时失败，因为它无法完全扩展/实现新版本。 但是，对于课程，有一个方便的解决方法：

public abstract class Foo {
    internal Foo() { }
}

因为Foo的构造函数是内部的，所以我的程序集之外的任何人都不能扩展Foo。 因此，我可以向Foo添加新的抽象方法而不用担心向后兼容性，因为我知道另一个程序集中的类不能扩展Foo。

我的问题是，接口有类似的技巧吗？ 我可以创建一个公共接口，并以某种方式保证我的程序集之外的任何人都无法创建它的实现吗？

Answer 1

不，你做不到。 但是，考虑到接口的关键是通过定义契约来定义实现的行为，这是有道理的。

但是，您可以创建一个继承自public interface的internal interface public interface ：

public interface IPublicInterface {
    /* set-in-stone method definitions here */
}

internal interface IChildInterface : IPublicInterface  {
    /* add away! */
}

这应该可以防止与其他程序集的任何向后兼容性问题，同时仍允许您隐藏其他方法。

当然，缺点是您需要记住在需要时将其转换为IChildInterface ，而不是简单地将其用作IPublicInterface

但是，老实说，如果你真的想定义一些仅汇编功能，同时仍然要求最终用户为某些方法定义自己的实现，那么你最好的选择可能是一个抽象类。

Answer 2

不，你不能。

但是因为在IL中，接口本质上只是一个纯粹的抽象类（即没有任何实现的接口），所以你可以使用你已经描述过的技术，它实际上是相同的。

如上所述，请记住，此方法确实会限制您的类型继承伪造的“抽象类”接口。 它可以实现其他接口，但不能继承任何其他类型。 根据情况，这可能是也可能不是问题。

如果它让您对设计感觉更好，请按照接口的.NET约定命名纯抽象类。 例如IFoo而不是Foo 。

当然，它确实暗示了一个问题：你为什么要这样做？ 如果您根本没有实现，允许其他代码实现您的接口会带来什么危害？

但从实际角度来看，可以按照自己的方式执行规则。