C# 抽象類 vs 介面：核心區別、選型原則與設計模式實戰

「抽象類」與「介面」是 C# 面向對象設計的兩大支柱，混淆二者會導致架構僵化、擴展困難。本文從語法限制、語義本質、版本控制、設計模式四個維度，建立清晰的選型決策模型。

一、 語法層面硬性對比

二、 語義本質：is-a vs can-do

抽象類 = 「是一種」：定義核心身份、共享狀態與行為骨架。
介面 = 「能做什麼」：定義行為契約、能力標簽，無狀態耦合。

• 緊密相關 的類型族系 → 抽象類 (如 Animal → Dog/Cat、Stream → FileStream/MemoryStream)。
• 鬆散關聯 但共享能力 → 介面 (如 IDisposable、IComparable、ISerializable)。

三、 版本演進與二進制兼容性

結論：預計頻繁擴展成員 → **抽象類**；穩定契約、廣泛分發 → **介面**。

四、 設計模式中的角色分工

1. Template Method (模板方法)：抽象類定義算法骨架，派生類填充步驟。
2. Strategy (策略)：介面定義算法契約，具體策略類實現，運行時注入。
3. Factory Method (工廠方法)：抽象類/介面聲明工廠方法，子類/實現類決定產品類型。
4. Decorator (裝飾器)：介面定義核心操作，裝飾器實現介面並持有被裝飾者介面引用。

五、 避坑指南：接口污染與組合優於繼承

• 接口污染：單一介面包含過多不相關方法，導致實現類被迫實現無用功能 (拋出 NotImplementedException)。
  → 拆分為細粒度介面 (Interface Segregation Principle)。
• 繼承層次過深：調用葉子類需加載整個繼承鏈元數據，啟動慢、內存大。
  → **組合/委託** 替代繼承 (如 Page.Server 實為 HttpServerUtility 實例)。
• 抽象類實現介面：可將介面方法映射為 abstract 方法，延遲到具體子類實現。

六、 決策流程圖

需要共享字段/構造函數/實現邏輯？ → YES → 抽象類
                                      ↓ NO
需要多實現/廣泛分發/穩定契約？   → YES → 介面
                                      ↓ NO
僅需提供默認行為供可選覆寫？     → YES → 介面 + 默認實現 (C# 8+)
                                      ↓ NO
考慮具體類 + 組合

「抽象類定義骨架，介面定義契約，組合構建對象。」—— 這是應對變化、控制複雜度的鐵三角。