我和我的同事們正在研究如何通過我們的新的UI控件在我們的大型遺留代碼庫替換第三方的WinForms controlls UI控件。實際上，我們想要替換繼承鏈中的第三方控制。通過對第三方UI控件進行子類化，第三方控件被用於數十個位置。我們希望儘可能安全地執行此更改，並在整個解決方案中儘可能少更改代碼。你有什麼經驗如何開始？顯然，繼承意味着強大的耦合，所以我希望在這裏找到不那麼痛苦的解決方案。更換第三方Windows窗體在一個大的代碼庫
就是「分支通過抽象」概念適用嗎？
這是一個基於代碼庫的團隊的瞭解，以及工作流程相當主觀的決定。好的一面是，你已經將所有的控件分類了，所以你已經完成了能夠提供代碼尋找的任何屬性的繁瑣工作。
鑑於這是的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;
可以防止與屬性序列化（商量好了就可以在this SO question，但是這僅僅是一個你可能會打一些例子
我不認爲有一個真正的。模式在這裏遵循，除非你的意思是在源代碼控制層面，在這種情況下，我會說絕對創建一個新的branch除了你的常規開發之外;誰知道什麼樣的障礙，你可能會打，你想擱置你的對於一些工作。
最終，你可能會認爲它只是b最好把它吸起來，撕掉舊的組件並放入新的組件，但如前所述，這是非常主觀的。這是這樣的情況，使我真的很喜歡WPF和MVVM模型，因爲你可以完全撕掉UI並保持業務邏輯完整。