打破界面

Question

如果需要中断.NET应用程序中的接口，需要遵循的最重要的准则是什么？在部署应用程序之前和之后，这些指导原则是如何更改的？

我知道还有其他问题在争论应该在什么时候/在哪里使用接口，但我不想深入讨论这个问题。我只想知道一些有效的方法，当你需要这样做时，可以减轻对应用程序其余部分的影响。

如果我只是向接口添加新方法，是否只需要实现者修改/重新编译，而所有客户端都可以继续愉快地操作，而不需要更改？

重命名方法和变量会破坏接口吗？

我在过去遇到的一个强烈建议是“永远不要破坏界面”。但是，这不会产生一个混乱的设计，如IDocument、IDocument2、IDocument3、IDocument4、IDocument5、IDocument6等，就像mshtml COM库中看到的那样吗？

Answer 1

这取决于与接口使用者之间的协定(隐含的或明确的)。

如果当你重建界面时所有的消费者都被重建了，那么管理改变它是很简单的，只需改变它并修复所有的中断(修复中断本身可能很复杂)。

如果你希望消费者在每次发布新的库/应用程序时都要重新编译，那么你需要向他们提供一些帮助，以指示需要进行哪些更改，您如何管理这取决于在保留旧函数/属性的同时发生哪些更改。如果您能够明智地在至少一个版本中使用过时(“使用新的Blah方法代替”，false)，然后在下一个版本中使用过时(“...”，true)，将提供一条干净的迁移路径

如果你试图保持二进制兼容性，那么过时的属性就可以做到这一点，同时仍然阻止人们在重新编译时继续使用被弃用的功能。

如果你的合同意味着要保持二进制和源代码的兼容性，比如说5年( OS平台API的一小段时间)，那么你别无选择，只能使用一个全新的接口，向接口添加方法将破坏实现它的代码(无论是在编译时，在类型验证时，还是在方法调用时，取决于类型加载器的严格程度)。

Answer 2

这当然取决于技术。在COM中(当不使用IDispatch后期绑定时)，您可以安全地在接口的末尾添加新方法，但不能在不更改接口GUID的情况下移除或交换以前存在的方法。Microsoft RPC也是如此。老客户仍然可以很高兴地使用接口，就像它只有他们知道的方法一样。