我對「良好的編程實踐」有更多的疑問。 我剛開始一個非常大的項目。我正在使用WebGui（長話短說，它是網絡中的WinForms） - 但它並不重要。處理控制靈活性
我創建的形式milions與控制milions像TextBox，NumericUpDown，DateTimePicker等可能會發生，我將不得不改變在DateTimePicker或外觀的行爲的東西。在每個控制中都不可能改變它。我想我的項目是靈活的，所以我有一個想法..
我做每個類型的字符串，數字，日期，字節..和我將分開的TextBox的自定義控件。而且在每一個表單上我都不會放TextBox，而是MyTextBox。事實上，MyTextBox只是TextBox，但是當我改變某些東西時，每一個控件都會改變。
這是好的，在編程流行的實踐嗎？
在WPF的情況下，這可以很容易地使用樣式和模板來實現。 在Winforms中這是不可能的，因此我會說你從控件派生出來並在UI上使用自己的自定義控件的方法是一種很好的實用方法，它有助於集中管理更改。
如果控件是在程序中手動創建的，或者您可以使用Factory類，並讓工廠創建控制器對象，而不是僅僅創建新對象。 但是，當通過拖放控件創建UI時，這可能無法實現，因爲開發人員無法控制控件的創建。
您選擇哪種方法，基本目標應該是集中控制的創建邏輯。
在winforms中不可能？ – 2012-07-09 23:10:38
是的，如果標準控件不能滿足您的要求，這對於GUI開發來說是完全正常的編程實踐。
大多數開發人員獲得第三方控制套件的額外靈活性。遠期購買的好處權衡您自己構建核心控制的好處。
我在一個地方做過companyTextBox，companyDatePicker，它工作正常。一些控件通過.Net版本進行了修改，因此這些基本分類控件需要進行一些手術。任何折舊控件都留作框架版本。
對於特殊情況，我會對CodeProject，CodePlex，Code.Google.com等良好的自定義控件進行大量研究，並將其實施到我正在開發的項目中。 否則請使用我正在使用的公司的庫存標準控件或第三方控件套件。
我的建議是獲得第三方控件套件，並根據第三方控件製作大量可重用的用戶控件。這樣，您可以通過將用戶控件拖放到表單上來構建大部分200個表單。通過創建，檢索和更新每個用戶控件實現接口&刪除表單一般與您的用戶控件配合使用的方法。
當您使用逼真的數字時，建議回答可能會更容易。我懷疑你會用數百萬的控件創建數以百萬計的表單。是否有描述應用程序功能的文檔？有多少次這樣的變化預計會發生？ – Stijn 2012-07-06 12:29:22
那麼，我不能給你看這個文件。我肯定會說200多個表格，所以對我來說這是「數百萬」。我不知道多久..當我的客戶會改變主意，並會說datetimepicker sux ..是的，他可能會付錢，但我不想整個星期浪費那種工作。 – Marshall 2012-07-06 13:00:29
不需要顯示文檔，只有重要的是你有一個。在開發過程中徵求客戶意見非常重要，以儘可能避免這些情況。也許有可能通過CSS實現這些可能的變化？這取決於變化的類型。 – Stijn 2012-07-06 13:17:35