如果需要破坏.NET应用程序中的界面，最重要的指导原则是什么？在部署应用程序之前和之后，这些指南如何变化？
我知道还有其他问题需要讨论何时/何地应该使用接口，但我不想深入研究。我只是想知道一些有效的方法，以便在需要时减轻对应用程序其余部分的影响。
如果我只是在界面中添加新方法，那么只有实现者需要修改/重新编译，而所有客户端都能继续快乐地运行而不需要进行任何更改吗？
如何重命名方法和变量，这会破坏界面吗？
我过去遇到的一个强烈推荐是“永不破坏界面”。但是这不会产生一个混乱的设计，如IDocument，IDocument2，IDocument3，IDocument4，IDocument5，IDocument6等，如mshtml COM库中所见？
答案 0 :(得分：4)
这取决于与您的界面的消费者的合同（暗示或明确）。
如果在重建界面时重建所有消费者，那么管理更改它很简单，只需更改它并修复所有中断（修复中断本身可能很复杂）。
如果您希望消费者在发布新库/应用程序时重新编译，那么您需要向他们提供一些帮助以指出需要进行哪些更改，您如何管理这取决于在维护时可能发生的更改旧的功能/属性。如果您可以在下一个版本中至少在一个版本中使用[Obsolete（“使用新的Blah方法代替”，false）]，然后[Obsolete（“...”，true）]将提供干净的迁移路径
如果您尝试维护二进制兼容性，那么Obsolete属性允许这样做，同时仍然阻止人们在重新编译时继续使用已弃用的功能。
如果您的合同意味着要维护二进制和源代码兼容性，比如5年（OS平台API的短时间），那么您别无选择，只需使用全新的界面，将方法添加到接口将破坏实现它的代码（在编译，类型验证或方法调用时，取决于类型加载器的严格性）。
答案 1 :(得分：1)
这当然取决于技术。在COM中（当不使用IDispatch后期绑定时），您可以在接口的末尾安全地添加新方法，但不能在不更改接口GUID的情况下删除或交换以前存在的方法。同样适用于Microsoft RPC。老客户仍然可以使用界面，因为它只有他们所知道的方法。