部署後的基底類別設計變更
更新：2007 年 11 月
於觀念上，在部署之後決不會變更類別階層架構，因為甚至小變更也會有非預期結果的風險。就現實狀況而言，有時候無法避免此類變更：產品需求會變更，並且有時候設計規格會遺漏關鍵項目。其中一種繼承 (Inheritance) 問題的類別稱為「易損壞的基底類別 (Base Class) 問題」。
易損壞的基底類別問題
使用繼承階層架構的主要缺點是一項稱為「易損壞的基底類別」的問題。變更基底類別通常需要變更、重新編譯並重新散發基底類別及衍生類別中的所有程式。當有多位開發人員撰寫基底類別及衍生類別時，因為每一方都會拒絕存取其來源程式碼，所以此問題會更加困難。在最壞的情況下，客戶可能會不慎使用以原始且不相容二進位版本的衍生類別所更新之基底類別的編譯二進位形式。
可能會破壞衍生類別的基底類別變更，包括了覆寫或變更基底類別成員的資料型別。
使易損壞的基底類別問題降至最低限度
避免易損壞的基底類別問題的最佳方式是只變更衍生類別。然而這並非一直如此，因為在第一次釋放基底類別時，您需要考慮各種可能性；即使盡了最大努力，有時也無法避免意料之外的基底類別變更。
使用 MustInherit 類別及 MustOverride 方法有助於降低易損壞的基底類別問題，這是因為如此做會將實作詳細資料移至衍生類別，並且減少對變更基底類別的需求。然而，再次強調，即使具有最佳的規劃，仍然不一定可避免。
因為衍生類別中的遮蔽資料成員可降低與基底類別成員的命名衝突，所以也非常有用。
擴充基底類別功能的最安全方法是加入新成員。只有衍生類別使用 Overloads 關鍵字以從基底類別繼承方法，並且使用新名稱來引入新方法的情況下，才會破壞新成員。避免此問題的方式是，在衍生類別中明確指定什麼基底類別方法是您要藉由重新定義某基底類別的方法並委派 (Delegate) 給該基底類別以自基底繼承。
就某種意義來說，在某種程度上基底類別都很容易損壞。在最後的分析中，無法排除易損壞的基底類別問題，但是可透過謹慎設計類別階層架構以降低對變更基底類別的需求，並且透過在無法避免此類變更時來進行全面性測試，以使此問題降至最低限度。