C++ 必知必會 (二)：多型——契約、替換原則與健康的不知情

多型核心定義

• 多型類型：擁有虛擬函式的類別。
• 多型物件：具備多重型別身分的物件（如 AmOption 同時是 AmOption、Option、Deal、Priceable）。
• 多型基類：為滿足多型物件使用需求而設計的基類（介面契約）。

繼承的是介面契約，非實作

class Deal {}; 
class Priceable {};
class Option : public Deal, public Priceable {};  // 介面繼承
class AmOption : public Option {};                // 具體實作
class EurOption : public Option {};

AmOption 物件可透過 4 種介面操作。關鍵在於：基類定義「契約」（語法+語義承諾），派生類實現契約（「轉包商」角色）。

李氏替換原則 (LSP) 實踐

• 語法層面：基類介面的每個呼叫在派生類皆合法。
• 語義層面：Option* b = new AmOption; b->price() 應回傳價格，而非撥電話、列印文件。
• 一致性：d->price() 與 b->price()（b 指向同一 d）必須綁定同一實作、回傳相同結果。

虛擬與非虛擬函式的契約分工

• 虛擬函式：派生類必須實現契約核心行為（如 price()），允許行為差異但語義一致。
• 非虛擬函式：基類提供預設實作，派生類不應覆寫（b->update() 與 d->update() 綁定同一 Option::update），確保不變式。

多型程式碼的「健康不知情」

void process(Option* opt) {  // 只知 Option 契約
    double p = opt->price();
    opt->update();
}
// 新增 AsianOption 完全不影響 process()

• 通用程式碼操作基類介面，對具體派生類型「健康地不知情」。
• 新增/移除派生類不影響通用代碼（開放封閉原則）。
• 派生類只需知基類契約，不知通用代碼細節（依賴倒置）。

基類設計原則

1. 盡量為純介面（純虛擬函式 + 虛擬解構函式）。
2. 介面設計考慮使用者需求，而非實作便利。
3. 基類完全不知派生類細節，否則層次結構僵化難維護。