「在物件導向革命的最初幾年，我們將 LSP 視為指導『繼承的使用』的一種方式。然而，LSP 可以擴展到架構層面，只要簡單地違反可替代性，就會導致系統的架構受到大量額外機制的汙染」

取自: Clean Architecture (p.67 & p.69)

CH9: 開放封閉原則 (Liskov Substitution Principle, LSP)

• 起源
  • 1987 年，Barbara Liskov 提出定義子型態(Subtype)的方式: Data Abstraction and Hierarchy (1987)
  • 1994 年與 M.Wing 針對物件導向的結構層次(Hierarchy)共同提出了 A behavioral notion of subtyping (1994)

上面兩篇 Journal 僅供膜拜大神用，只是想讓讀者們感受現在看似直觀的軟體設計原則們，都是當年大神們嘔心瀝血的結晶。僅以此感謝這些人的付出
LSP 或許是五大原則中最需花時間理解、也最難完全遵守的一個...

Check List

符合 LSP 的繼承關係需至少滿足下列 7 條規則 (Rules)
前三條是最重要的，好的繼承至少不能違反這三條
Ref: What is an example of the Liskov Substitution Principle?

1. 先決條件不能被強化 (Pre-conditions cannot be strengthened)
   ...
2. 後置條件不能被弱化 (Post-conditions cannot be weakened)
   ...
3. 不變量必須被保留 (Invariants must be preserved)
   ...
4. 衍生類別拋出的例外型別也要衍生自父類別 (No new exceptions should be thrown in derived class)
   ...
5. History Constraint (aka History Rule)
   有點難翻譯，類似強制使用 setter 來封裝 private 屬性的意思，避免子類亂改到父類的 private
   "Objects are regarded as being modifiable only through their methods (encapsulation)"
6. Contravariance of method arguments
   ...
7. Covariance of return types
   ...

範例一: License

製圖...

範例二: 正方形 / 矩形問題

// 產 Code

小結

"If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of the program"

取自: https://en.wikipedia.org/wiki/Liskov_substitution_principle

• 簡單來說，LSP 就是在倡導父類別與子類別之間應當要能夠互相替換，而不影響現有功能，使我們得以放心使用多型
• 而擴展到架構層面，即是要我們思考，架構中的元件是否有辦法做到互相替換呢?
• LSP 給我們的啟示
  1. 「Subclass」 僅注重在程式碼的複用 (Code Reuse)、是一種依賴性極強的繼承方式
  2. 「Subtype」 是更好的繼承使用方式，除了 Code Reuse 之外，也間接符合了 OCP 原則，使我們能建構出更有彈性的類別架構
• 最後，不管讀者對於 7 條 Rules 的理解如何，切記:
  不要一看到共同的 Code 片段就想用繼承提取出來

Reference

• 里氏替換原則 LSP｜先聽爸爸說
• 使人瘋狂的 SOLID 原則：里氏替換原則 (Liskov Substitution Principle)
• 深入淺出 Liskov 替換原則 Liskov Substitution Principle