我和我的同事正在研究如何在我们的大型遗留代码库中用新的UI控件替换第三方WinForms控件。实际上，我们想取代继承链中的第三方控制权。通过对第三方UI控件进行子类化，第三方控件被使用了几十个位置。我们希望尽可能安全地执行此更改，整个解决方案的代码更改最小。你有如何开始的经验吗？显然，继承在这里意味着强耦合，所以我想在这里找到一个不那么痛苦的解决方案。
"抽象分支"的概念在这里适用吗？
这是一个非常主观的决定，基于您的团队对代码库和工作流的理解。好的一面是，您已经对所有控件进行了子类化，因此您已经完成了能够提供代码想要编译的任何属性的乏味工作。
考虑到这是WinForms，这应该更简单，因为控件大小和位置是在Control级别上设置的。您需要担心将旧供应商控件中存在的属性/方法映射到新控件，而不必担心表单布局。这对于某些控件来说可能很简单，而对于其他控件(即网格)来说可能更复杂。
IMO最大的障碍是处理InitializeComponent中当前的设计时间序列化逻辑。如果您已经创建了一个从旧的->新的映射属性，那么您必须小心，当设计器在您打开表单并修改某些内容后重新序列化所有内容时，您可能不希望同时序列化旧属性和新属性。例如：
旧供应商
this.myOldComponent.Data = this.dataSource;
新供应商
this.myNewComponent.DataSource = this.dataSource;
在这种情况下，您可以考虑在子类化的新组件上创建一个名为Data的新属性，以便旧代码在不更改任何内容的情况下工作。假设您在设计的中打开表单，并将网格移动几个像素，从而使设计器序列化数据。您现在可能有：
this.myNewComponent.Data = this.dataSource;
this.myNewComponent.DataSource = this.dataSource;
您可以阻止使用属性进行序列化(在这个SO问题中对此进行了很好的讨论，但这只是您可能遇到的问题的一个示例
我不认为这里真的有一个模式可以遵循，除非你的意思是在源代码管理级别，在这种情况下，我会说，除了常规开发之外，绝对要创建一个新的branch；谁知道你会遇到什么样的障碍，你会想把你的工作搁置一段时间。
最终，你可能会决定，最好把它吸起来，去掉旧的组件，放入新的组件，但正如所提到的，这是非常主观的。正是这种情况让我非常喜欢WPF和MVVM模型，因为您可以完全剥离UI并保持业务逻辑的完整性。