Day 19: SOLID 设计原则 — LSP (待改进中... )

「在物件导向革命的最初几年，我们将 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