設計原則入門:里氏替換原則 Liskov Substitution Principle

閱讀時間約 2 分鐘

你有沒有遇到過這種情況:當你在開發過程中,使用了子類別替換父類別,結果卻發現程式變得不正常了?這很可能是你違反了「里氏替換原則 (Liskov Substitution Principle, LSP)」。LSP 是物件導向設計中的一個重要原則,能確保我們使用繼承時不會破壞程式的穩定性。


什麼是里氏替換原則?

里氏替換原則它強調:「子類別應該可以無縫替換父類別,而不會影響程式的正確性」。換句話說,在程式中某個地方用的是父類別,未來改成子類別後,程式還能正常運作。


這裡的核心思想是:繼承不只是重用父類別的程式碼,而是要確保子類別能「完美替代」父類別。如果某個子類別改變了父類別的行為邏輯,可能會破壞程式的穩定性。


舉個簡單的例子

想像有一個基礎類別叫做「鳥」,裡面有一個方法是「飛行」。如果我們繼承了一個新的類別叫「企鵝」,因為企鵝不能飛,這時候問題就來了。如果我們強制企鵝也有「飛行」這個行為,那麼當程式要求企鵝飛時,程式就會崩潰或出錯,因為它實際上無法做到。


正確設計的應該怎麼做?

所以在這個例子中,我們應該避免讓企鵝繼承那個飛行行為,那麼正確的做法是,我們可以把「飛行」行為拆分到另一個更適合的類別,而不強制所有鳥類都必須會飛。讓只有會飛的鳥類才有「飛行」這個行為,這樣一來,會飛的鳥類和不會飛的鳥類就不會再混淆,這樣的設計不僅清晰也變得更合理,還能避免潛在的錯誤,也符合里氏替換原則。


正確的設計應該是讓不同的類別各自處理自己的行為,而不是強行讓不相關的子類別擁有父類別的所有特徵。這樣可以確保子類別能夠替代父類別,而不會破壞系統的穩定性。


為什麼要遵守 LSP?

遵守 LSP 有助於程式的穩定性和可預測性。當子類別能無縫替代父類別時,系統就能更容易地進行維護與擴展。相反地,違反 LSP 的設計則容易引發隱藏的錯誤,這些錯誤往往難以發現跟修正。


總結一下,里氏替換原則是一種設計上的「最佳實踐」,幫助開發者更好地處理繼承關係,它還代表著更好的程式設計習慣和更健全的系統架構。


有興趣深入體會設計原則的朋友,可以參考我今年在iThome鐵人賽的文章。
https://ithelp.ithome.com.tw/articles/10355395


    avatar-img
    6會員
    83內容數
    對於經營自媒體、部落格或社群媒體感興趣?我專注於提供實用的寫作技巧、數位行銷策略,以及個人成長建議。 每週,我會分享提升寫作技巧、優化部落格經營、有效管理社群媒體、以及投資理財的寶貴知識。追蹤我,獲得實用的工具和建議,讓你的個人品牌和財務管理更上一層樓!
    留言0
    查看全部
    avatar-img
    發表第一個留言支持創作者!
    ShengYu的沙龍 的其他內容
    你有沒有遇過這樣的情況?當你設計一個系統時,一開始覺得一切順利,結果過了不久,客戶突然要求增加新功能。問題來了,每次改需求,你的程式碼都變得一團混亂,越改越多錯誤,最後讓你崩潰了。 軟體開發中需求變動是常態,但每次修改都得動到核心程式碼,難免會增加出錯的風險,也讓開發效率大打折扣。今天就要來聊聊「
    在寫程式的過程中,你是否遇過一個類別或模組負責了太多事情,結果導致程式變得難以維護?這類情況經常被稱為「巨石類別 (God Class)」。當我們對這樣的類別做出任何變更時,改動可能會牽一髮動全身影響其他部分,這時候「單一職責原則 (SRP)」便派上用場。 單一職責原則是什麼? 簡單來說,單一
    當你在開發應用程式時,可能會面臨要建立不同物件的需求。這時候簡單工廠模式(Simple Factory Pattern)是一個很實用的解決方案。今天我們就來用特斯拉汽車工廠的例子來解釋這個概念。 什麼是簡單工廠模式? 簡單工廠模式的核心思想是:將物件的建立過程封裝起來,客戶端(也就是使用者)只需要
    在學習設計模式時,可能會讓人感到困惑:「為什麼有這麼多種工廠模式?它們到底解決什麼問題?」工廠方法模式(Factory Method Pattern)提供了一種方式來建立單一物件,這個方法可以在子類中覆寫以產生不同的物件。而抽象工廠模式(Abstract Factory Pattern)在這個基礎上
    想像你是一位探險家,走進了一座神秘古城。這座城裡有著各種各樣的建築:宏偉的宮殿、莊嚴的神廟、熱鬧的市集。每個地方都有它獨特的風格和探索方式。作為探險家,你必須用不同的方法來了解每個地方,但你不需要改變這些建築本身,只要隨著地方變化調整探索的方式。這就是訪問者模式的精髓! 什麼是訪問者模式?
    想像你有一個非常珍愛的玩偶,這個玩偶獨一無二。如果你想要再擁有一個完全相同的玩偶,你會怎麼做呢?自己重新製作一個,可能需要很多時間和心力,但如果有一台神奇的「複製機」,只需按下按鈕,就可以立即產生一個一模一樣的玩偶,這會不會很輕鬆方便?這就是「原型模式(Prototype Pattern)」的核心概
    你有沒有遇過這樣的情況?當你設計一個系統時,一開始覺得一切順利,結果過了不久,客戶突然要求增加新功能。問題來了,每次改需求,你的程式碼都變得一團混亂,越改越多錯誤,最後讓你崩潰了。 軟體開發中需求變動是常態,但每次修改都得動到核心程式碼,難免會增加出錯的風險,也讓開發效率大打折扣。今天就要來聊聊「
    在寫程式的過程中,你是否遇過一個類別或模組負責了太多事情,結果導致程式變得難以維護?這類情況經常被稱為「巨石類別 (God Class)」。當我們對這樣的類別做出任何變更時,改動可能會牽一髮動全身影響其他部分,這時候「單一職責原則 (SRP)」便派上用場。 單一職責原則是什麼? 簡單來說,單一
    當你在開發應用程式時,可能會面臨要建立不同物件的需求。這時候簡單工廠模式(Simple Factory Pattern)是一個很實用的解決方案。今天我們就來用特斯拉汽車工廠的例子來解釋這個概念。 什麼是簡單工廠模式? 簡單工廠模式的核心思想是:將物件的建立過程封裝起來,客戶端(也就是使用者)只需要
    在學習設計模式時,可能會讓人感到困惑:「為什麼有這麼多種工廠模式?它們到底解決什麼問題?」工廠方法模式(Factory Method Pattern)提供了一種方式來建立單一物件,這個方法可以在子類中覆寫以產生不同的物件。而抽象工廠模式(Abstract Factory Pattern)在這個基礎上
    想像你是一位探險家,走進了一座神秘古城。這座城裡有著各種各樣的建築:宏偉的宮殿、莊嚴的神廟、熱鬧的市集。每個地方都有它獨特的風格和探索方式。作為探險家,你必須用不同的方法來了解每個地方,但你不需要改變這些建築本身,只要隨著地方變化調整探索的方式。這就是訪問者模式的精髓! 什麼是訪問者模式?
    想像你有一個非常珍愛的玩偶,這個玩偶獨一無二。如果你想要再擁有一個完全相同的玩偶,你會怎麼做呢?自己重新製作一個,可能需要很多時間和心力,但如果有一台神奇的「複製機」,只需按下按鈕,就可以立即產生一個一模一樣的玩偶,這會不會很輕鬆方便?這就是「原型模式(Prototype Pattern)」的核心概
    你可能也想看
    Google News 追蹤
    Thumbnail
    這個秋,Chill 嗨嗨!穿搭美美去賞楓,裝備款款去露營⋯⋯你的秋天怎麼過?秋日 To Do List 等你分享! 秋季全站徵文,我們準備了五個創作主題,參賽還有機會獲得「火烤兩用鍋」,一起來看看如何參加吧~
    Thumbnail
    11/20日NVDA即將公布最新一期的財報, 今天Sell Side的分析師, 開始調高目標價, 市場的股價也開始反應, 未來一週NVDA將重新回到美股市場的焦點, 今天我們要分析NVDA Sell Side怎麼看待這次NVDA的財報預測, 以及實際上Buy Side的倉位及操作, 從
    Thumbnail
    Hi 大家好,我是Ethan😊 相近大家都知道保濕是皮膚保養中最基本,也是最重要的一步。無論是在畫室裡長時間對著畫布,還是在旅途中面對各種氣候變化,保持皮膚的水分平衡對我來說至關重要。保濕化妝水不僅能迅速為皮膚補水,還能提升後續保養品的吸收效率。 曾經,我的保養程序簡單到只包括清潔和隨意上乳液
    Thumbnail
    本章介紹了 PHP 中的例外處理技術,包括其語法、常見異常類型以及如何主動觸發異常訊息。我們還學習了如何自定義異常類別,以便更好地管理和處理不同類型的異常情況。通過使用例外處理,可以提高程式碼的穩定性、可讀性和可維護性,並提供更優雅的錯誤信息處理機制。
    Thumbnail
    本章節的目的是介紹在TypeScript中如何進行例外處理。涵蓋了例外處理的重要性、語法、常見異常類型以及如何主動觸發異常訊息及用戶自定義異常訊息。為讀者提供了全面而深入的了解,以提高程式的可靠性、提供更好的反饋、增加程式的容錯性以及改善程式的可讀性。
    ※ 單例模式介紹 ※ 定義:單例模式是一種設計模式,確保一個class(類)只有一個實例,並提供一個存取它的全域存取點。無論如何取值,皆只對這個實例取值。 ※ 目的:保證一個類別只會產生一個物件,而且提供存取該物件的統一方法。 ※ 講解:單例模式確保一個類無論怎麼 new 或 get,都只能拿
    Thumbnail
    當你在開發程式時,難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性,我們使用「例外處理」來處理這些異常情況。
    讓我在這篇文章總結一下前面對物件導向設計的討論,我們討論了物件導向的四個特性:繼承、抽象、多型、封裝,分析了它們的問題,並跟函數式編程的思維做比較。我們引入了與之相對應的特性:泛型、特性系統、模組化,有些特性雖然跟那四個特性很像,但在一些細微的地方有不同的詮釋,使得整體思考方式很不一樣。 「繼
    物件導向設計的一個重點就是封裝,這有很多層面上的意義,但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關,這使得有一些時候我們逼不得已必須把函式定義在類別上,這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責,並不需要再給物件相同的能力。 一般的模組系統就是把相
    Thumbnail
    在先前的型別文章中,我們曾經聊過 JavaScript 常用的一些型別,但針對布林這個型別,我們沒有做太多的解釋,原因在於布林值在 JavaScript 會有一個特殊的規則:自動轉型 。 自動轉型可說是讓 JavaScript 為弱型別、且難以管理的最重要的要素,接著就來讓我們來聊聊什麼是自動轉型
    上一篇文章提到有些介面不應被繼承,但物件導向的子類別只能繼承父類別的介面,因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制,這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承,更適合使用組合,根本不需要使用繼承疊加特性。 資料類型的定義往往跟怎麼建構模型相
    類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的
    Thumbnail
    這個秋,Chill 嗨嗨!穿搭美美去賞楓,裝備款款去露營⋯⋯你的秋天怎麼過?秋日 To Do List 等你分享! 秋季全站徵文,我們準備了五個創作主題,參賽還有機會獲得「火烤兩用鍋」,一起來看看如何參加吧~
    Thumbnail
    11/20日NVDA即將公布最新一期的財報, 今天Sell Side的分析師, 開始調高目標價, 市場的股價也開始反應, 未來一週NVDA將重新回到美股市場的焦點, 今天我們要分析NVDA Sell Side怎麼看待這次NVDA的財報預測, 以及實際上Buy Side的倉位及操作, 從
    Thumbnail
    Hi 大家好,我是Ethan😊 相近大家都知道保濕是皮膚保養中最基本,也是最重要的一步。無論是在畫室裡長時間對著畫布,還是在旅途中面對各種氣候變化,保持皮膚的水分平衡對我來說至關重要。保濕化妝水不僅能迅速為皮膚補水,還能提升後續保養品的吸收效率。 曾經,我的保養程序簡單到只包括清潔和隨意上乳液
    Thumbnail
    本章介紹了 PHP 中的例外處理技術,包括其語法、常見異常類型以及如何主動觸發異常訊息。我們還學習了如何自定義異常類別,以便更好地管理和處理不同類型的異常情況。通過使用例外處理,可以提高程式碼的穩定性、可讀性和可維護性,並提供更優雅的錯誤信息處理機制。
    Thumbnail
    本章節的目的是介紹在TypeScript中如何進行例外處理。涵蓋了例外處理的重要性、語法、常見異常類型以及如何主動觸發異常訊息及用戶自定義異常訊息。為讀者提供了全面而深入的了解,以提高程式的可靠性、提供更好的反饋、增加程式的容錯性以及改善程式的可讀性。
    ※ 單例模式介紹 ※ 定義:單例模式是一種設計模式,確保一個class(類)只有一個實例,並提供一個存取它的全域存取點。無論如何取值,皆只對這個實例取值。 ※ 目的:保證一個類別只會產生一個物件,而且提供存取該物件的統一方法。 ※ 講解:單例模式確保一個類無論怎麼 new 或 get,都只能拿
    Thumbnail
    當你在開發程式時,難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性,我們使用「例外處理」來處理這些異常情況。
    讓我在這篇文章總結一下前面對物件導向設計的討論,我們討論了物件導向的四個特性:繼承、抽象、多型、封裝,分析了它們的問題,並跟函數式編程的思維做比較。我們引入了與之相對應的特性:泛型、特性系統、模組化,有些特性雖然跟那四個特性很像,但在一些細微的地方有不同的詮釋,使得整體思考方式很不一樣。 「繼
    物件導向設計的一個重點就是封裝,這有很多層面上的意義,但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關,這使得有一些時候我們逼不得已必須把函式定義在類別上,這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責,並不需要再給物件相同的能力。 一般的模組系統就是把相
    Thumbnail
    在先前的型別文章中,我們曾經聊過 JavaScript 常用的一些型別,但針對布林這個型別,我們沒有做太多的解釋,原因在於布林值在 JavaScript 會有一個特殊的規則:自動轉型 。 自動轉型可說是讓 JavaScript 為弱型別、且難以管理的最重要的要素,接著就來讓我們來聊聊什麼是自動轉型
    上一篇文章提到有些介面不應被繼承,但物件導向的子類別只能繼承父類別的介面,因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制,這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承,更適合使用組合,根本不需要使用繼承疊加特性。 資料類型的定義往往跟怎麼建構模型相
    類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的