設計原則 - 里氏替換原則 Liskov Substitution Principle

你是否曾經遇到過這樣的情況：你寫了一個子類別，卻發現當它被應用於父類別的場景時，程式突然出現了問題？這其實是違反了「里氏替換原則 (Liskov Substitution Principle, LSP)」的例子。LSP 是面向物件設計中的一個重要原則，能幫助我們在使用繼承時保持程式的穩定性。

什麼是里氏替換原則？

簡單來說，里氏替換原則強調：所有的子類別應該可以替換掉它們的父類別，而不會影響程式的正確性。也就是說，如果你的程式原本使用的是父類別，那麼它也應該能夠正常使用任何一個子類別而不會出錯。

這個原則是對繼承的一種保障：繼承不是僅僅為了重複使用父類別的程式碼，而是為了保證「子類別能夠完全取代父類別」。如果子類別的行為和父類別不同，甚至違反了父類別的預期，那麼就會破壞系統的穩定性，這就是違反 LSP 的表現。

里氏替換原則的例子

讓我們來看一個簡單的例子，理解什麼樣的設計違反了里氏替換原則。

錯誤的設計，違反里氏替換原則

假設我們有一個 Bird 類別，以及繼承它的 Penguin 類別：

class Bird {
public:
    virtual void fly() {
        // 鳥類的飛行行為
    }
};

class Penguin : public Bird {
public:
    void fly() override {
        throw std::logic_error("Penguins can't fly!");
    }
};

在這個例子中，Penguin 類別違反了 LSP，因為當程式預期所有的 Bird 都能飛時，Penguin 的 fly 方法卻會拋出異常，這顯然不是正確的行為。雖然企鵝是鳥類，但它不能飛，這導致了子類別無法正常替換父類別。

正確的設計，遵守里氏替換原則

要解決這個問題，我們應該重新思考類別的設計。或許「飛行」不應該是所有鳥類的共同行為，而應該是飛行鳥類的特徵。因此，我們可以將飛行行為從 Bird 類別中移除，並且將其移到專門處理飛行鳥類的類別中：

class Bird {
    // 一般鳥類的屬性與行為
};

class FlyingBird : public Bird {
public:
    virtual void fly() {
        // 飛行行為
    }
};

class Penguin : public Bird {
    // 企鵝的行為，無需實現 fly 方法
};

經過重新設計後，現在 Penguin 類別不需要再拋出異常，因為它不會被要求飛行，而 FlyingBird 類別則專注於飛行鳥類的行為。這樣的設計遵守了 LSP，因為 Penguin 不再被強迫擁有與其不符合的行為。

為什麼這麼做？

遵守里氏替換原則能夠讓程式更具穩定性與可預測性。當你的子類別能夠無縫替換父類別時，系統能夠更有效地進行擴展，維護起來也更加容易。

不遵守 LSP 的問題在於，當子類別無法替換父類別時，往往會導致難以發現的錯誤。這些錯誤可能在某些特定情境下才會顯現出來，這使得除錯變得非常困難。

此外 LSP 的好處在於保持繼承的正確性與一致性。當我們設計一個基底類別時，我們期望所有的子類別都能遵循同樣的行為規範，而不是為每一個子類別設定不同的特例。遵守 LSP 意味著我們的設計是穩定且易於預測的，這對於大型專案來說至關重要。

當然，過度應用繼承或過於強求遵守 LSP 可能會導致程式碼設計變得複雜，因此在實踐中，我們應該根據具體需求靈活應用這一原則。

實際應用

LSP 在實際應用中是非常常見的，尤其是在框架設計或 API 開發中尤為重要。設計一個良好的框架或函式庫時，確保子類別能夠無縫替換父類別，能夠讓開發者更加輕鬆地進行擴展和修改，而不必擔心破壞現有系統。

例如在 GUI 開發中，一個基礎的按鈕類別可能會被許多不同的按鈕類別繼承（如「送出按鈕」或「取消按鈕」）。這些子按鈕應該都能被替換為基礎的按鈕類別，而不會出現意外行為。遵守 LSP 可以讓整個界面的行為更為一致，也讓開發更為順暢。