閒談繼承與組合：從 GUI 框架演進看 OO 設計範式的歷史嬗變

「繼承是 OO 三大支柱」vs「組合優於繼承」，這對看似衝突的論斷，其實反映了軟體開發領域從 **GUI 密集型** 向 **業務建模/分層架構** 歷史演進的軌跡。

黃金時代：GUI 框架確立了繼承的統治地位 (80 末~90 初)

早期 OO 理論成型於 Smalltalk，但大規模落地是隨著 Windows 3.x / MFC / Java Swing 等 **圖形介面框架** 爆發。GUI 領域天然存在深層 is-a 體系：

• 所有視覺元素是 Window → Control → Button / Edit …
• 對話框是 Dialog，視窗是 Frame …

繼承層次極深：

• WPF Window：繼承鏈長達 9 層 (DispatcherObject → DependencyObject → Visual → UIElement → FrameworkElement → Control → ContentControl → Window)。
• Swing JFrame：6 層 (Object → Component → Container → Window → Frame → JFrame)。

此時開發者經驗：「繼承好用、層次深沒關係、能複用基類邏輯」，於是寫入教科書成為鐵律。

轉折點：兩層/三層架構與關係資料庫的衝擊 (90 中後期)

業務邏輯前移，核心難題變成 **實體建模** 與 **持久化**：

1. 實體關係多為關聯而非繼承：訂單「有」商品，客戶「下」訂單，很少是「是」關係。
2. 關係資料庫無原生繼承映射：ORM (Hibernate 等) 處理繼承需 Table per Class / Joined / Single Table 複雜策略，極大增加複雜度。
3. 分層架構要求低耦合：繼承造成緊耦合 (子類依賴父類實現細節)，跨層傳遞 DTO 時極不靈活。

於是現代 OO 理論 (GoF、Martin Fowler 等) 高舉「組合優於繼承」、「介面導向設計」，實則是針對 **領域模型層** 的矯正。

反思：極端化同樣危險

當前許多教材直接說「少用繼承」，卻不講 **何時適合繼承**，導致新手遇到明顯 is-a、行為需擴展、框架擴充點 (如 MFC CView、ASP.NET Controller) 時也不敢用繼承，反而濫用組合產生大量委派樣板碼。

判斷準則：什麼時候用繼承？

結語

繼承不是洪水猛獸，也不是萬能鑰匙。**理解其歷史語境、掌握適用邊界、在框架擴充與領域建模間切換思維模式**，才是成熟架構師的基本功。