抽象類別與介面深度解析：核心差異、設計規則與實戰準則（上）

抽象類別與介面是面向抽象程式設計的兩大基石，雖同樣無法直接實例化、皆支援多型，但設計意圖與適用場景截然不同。本文整理經典觀點、MSDN 建議與實戰經驗，建立決策框架。

核心異同速查表

經典觀點摘錄

dunai：抽象類別是具體類別的「最大公約數」；介面是將不相關類別「雜湊」成群體的契約。

shenfx：差異大的物件尋求共性 → 介面；共性大的物件尋求差異 → 抽象類別。

Dflying Chen：介面定義「溝通契約」；抽象類別封裝「共用行為」。

一醉解千愁：介面 = 粗略規範；抽象類別 = 規範+說明；類別 = 具體實作。

MSDN 官方建議決策樹

1. 預期多版本演進 → 抽象類別（更新基類自動惠及衍生類）
2. 跨越廣泛異構類別 → 介面（不相關類別的通用功能）
3. 小而單一功能塊 → 介面（如 IDisposable、IComparable）
4. 大型功能單元、需共享實作 → 抽象類別
5. 需提供預設實作 → 抽象類別

設計鐵律與最佳實務

介面設計

• 命名慣例：I 前綴（如 IRepository）
• 功能單一：一個介面一個職責
• 公開等級：預設 public
• 「介面不變」原則：擴充請新增介面（如 IRepositoryV2），勿修改既有介面

抽象類別設計

• 核心領域模型：表達「是一種」關係（如 Animal → Dog/Cat）
• 可定義 protected 建構式、共用欄位、虛擬/抽象方法
• 不可 sealed、不可 new 實例
• 抽象方法不可標註 static 或 virtual

版本策略對照

實戰判斷清單

面對新類別設計時，依序自問：

1. 這是否描述一個核心領域概念（IS-A）？→ 抽象類別
2. 是否需要跨越無關類別提供統一行為（CAN-DO）？→ 介面
3. 是否需要共享欄位/預設實作/建構邏輯？→ 抽象類別
4. 是否為值類型？→ 介面
5. 是否需支援回呼/事件訂閱？→ 介面
6. 預期頻繁演進版本？→ 抽象類別（或介面+擴充介面策略）

總結

「面向介面程式設計」不等於「盡量用介面」。抽象類別負責定義「是什麼」，介面負責定義「能做什麼」。架構師的智慧在於：在核心領域建立穩固的抽象類別階層，在系統邊界與橫切關注點以精簡介面定義契約，兩者互補，構建高內聚、低耦合、可演進的系統。

下一篇將以完整書店案例，示範兩者協作落地。