# 六角鼠年鐵人賽 Week 35 - Design Pattern - Liskov Substitution Principle

==大家好，我是 "為了拿到金角獎盃而努力著" 的文毅青年 - Kai==

## 曹操 孟德
:::info
老驥伏櫪，志在千里。 烈士暮年，壯心不已。
:::

## 主題
今天要介紹的設計原則是 **Liskov Substitution Principle**，又簡稱 LSP，中文常見名稱 **替換原則 (里氏替換原則)**

由 **Barbara Liskov 女士**在 1987 年的**物件導向開發技術高峰會 (OOPSLA)**，發表的 *Data Abstraction and Hierarchy* 中提出。

原文為:
> Inheritance should ensure that any property proved about supertype objects also holds for subtype objects

亦即繼承這件事情，必須要確保的是父類別的特性在繼承的子類別中依然成立。

Liskov Substitution Principle 主要闡述關於繼承這件事情所必須要有的原則，什麼狀況該使用繼承? 什麼狀況不該使用繼承?

以上次的 Car 例子來說，由 Benz, BMW, Tesla, Toyota 等車廠品牌去繼承是完全沒有問題的一件事情，但如果今天是玩具車呢? 照裡說他也是個 Car，而實際上來說我們都不會讓玩具車去繼承 Car，因為那跟我們原先預期的 "實際狀況" 不一樣，但程式不會這樣構思，如果我們真的讓玩具車繼承了 Car，程式也會照單全收，那就會變成不合現實的邏輯被寫進了系統中。

當 Car 所具備的方法，也必須在子類實現時，就會發生許多尷尬情況，例如車都需要適時補充燃料(油or電)，但玩具車卻不一定有燃料的需要，這就是 Liskov Substitution Principle 所要避免的狀況，父類別的特性無法全然的套用在子類別身上。

因此 Liskov Substitution Principle 可說是在規範父類別與子類別之間具體實現的關係，同時也協助補充了 Open Close Principle 所沒有做到的限制部分。

## 定義
Liskov Substitution Principle 並沒有實際列出任何的要求，但可以從總結的敘述中得出符合 Liskov Substitution Principle 的方式有哪些?

- 子類別可以實現父類別的抽象方法，但不能覆蓋父類別的一般方法
> 通過覆蓋，重新建構功能的方式，可能會導致父類別與子類別的方法在整個繼承過程中的功能可重複使用的特性降低，並且會提高多型狀況下出錯的機率

- 子類別可以增加自己特有的方法，且該方法與父子類別共同特性無關
> 但必須注意的是這類方法盡量避免寫得太多，畢竟在整個繼承過程中若要再使用大量的判斷式去處理邏輯的話，就失去了繼承的精神

- 當子類別要 Overload 父類別的方法時，子類別該方法輸入的參數條件要比父類別寬鬆
> 以父類別的方法條件為最高要求情況下去建構子類別方法，可以避免參數不齊的困擾

- 當子類別要 Override, Overload, Implements 父類別的抽象方法時，子類別該方法的返回條件要比父類別更嚴格或相等。(意即:返回的物件類型須與父類別相等或是為繼承其的物件)
> 以父類別回傳的物件為最低要求的情況下去建構子類的回傳物件，可以避免物件型態不相同或無法兼容的困擾

## 幫助
第一段的主題中提到了 Liskov Substitution Principle 幫助了 Open Close Principle 做到規範了繼承關係的部分，那到底實際上幫助了哪些部分?

身為工程師的各位一定理解但要說的時候卻無法明白講出的下面幾點:
1. 減少子類別 Override 變差的缺點 (當子類與父類特性相去太遠，在實現時產生的變異狀況)
2. 確保父類別與子類別的方法處理邏輯一致，降低擴展類別時出錯的可能性
3. 強化父類別與子類別的特性一致，降低後續擴展的風險和降低維護的難度

## 實例

以先前的 Car 來說，若要添加上玩具車這個子類別勢必會錯誤產生

因此就有其必要針對種類的類型不同，重新建構繼承父子類別的架構，使其能夠更符合現實需求與狀況

:::danger
在慢慢實際接觸了許多設計原則與模式後，對於當初的懵懵懂懂到現在開始能夠說清楚的感覺很棒，Kai 會繼續學習，並把學到的知識分享在這裡~
:::

首頁 [Kai 個人技術 Hackmd](/2G-RoB0QTrKzkftH2uLueA)

###### tags: `Design Pattern`,`w3HexSchool`