.net 中断接口

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

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

如果我只是将新方法添加到接口中，那么是否只有实现者需要修改/重新编译，而所有客户机都可以在不需要更改的情况下继续愉快地运行

重命名方法和变量怎么样，这会破坏接口吗

---

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

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

这取决于与界面使用者的合同（暗示或明确）

如果重建界面时重建了所有使用者，那么管理更改界面很简单，只需更改界面并修复所有中断（修复中断本身可能很复杂）

如果您希望消费者在您发布新库/应用程序时重新编译，则您需要向他们提供一些帮助，以指示需要进行哪些更改，您如何管理这些更改取决于在维护旧功能/属性的同时可能发生的更改。如果您能够在至少一个版本中明智地使用[Observe（“改用新的Blah方法”，false）]，然后在下一个版本中使用[Observe（“…”，true）]，将提供一个干净的迁移路径

如果您试图保持二进制兼容性，那么过时的属性允许这样做，同时仍然阻止人们在重新编译时继续使用不推荐的功能

---

如果您的合同意味着二进制和源代码的兼容性要保持5年（操作系统平台API的短时间），那么您别无选择，只能使用一个全新的接口，向接口添加方法将破坏实现它的代码（编译时、类型验证时或方法调用时，具体取决于类型加载器的严格程度）。

感谢您的回答。我决定将重点放在.NET平台上，因为我的问题可能有点过于宽泛。