WadeHuang的學習迷航記

里氏替換原則（Liskov Substitution Principle） 定義 Subtypes must be substitutable for their base types. - 子類別必須能取代父類別 里式替換原則是從 開放封閉原則 延伸出來的原則，若對開放封閉原則還不了解，建議先去瞭解開放封閉原則如何透過引入抽象來擴充程式碼的行為，再來學習里氏替換原則！

系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則，Why SOLID? SRP 單一職責原則，定義、解析與實踐 物件導向設計原則：開放封閉原則，定義、解析與實踐 Why SOLID? 在 前一篇文章 中介紹 SOLID 對一個工程師的影響，這裡再稍微補充一下為什麼軟體開發會需要 SOLID 原則？ 軟體複雜的本質 專案經常會歷經「商業邏輯調整」和「快速且多變的需求」，這都不是開發環節所能控制的，但是一個專案會「遇到困難」常常是因為  糟糕的程式設計  和其他技術層面導致。 其中  糟糕的程式設計  又可分成三個因素： 程式碼變更 Bug 修復 複雜度控制 在添加功能前應該  閱讀代碼並細心設計 ，但實際上更常發生的是，開發者選擇 直接在程式碼上面堆疊新的程式碼 。 新舊版本  和  意圖不同  的程式碼錯綜複雜之下，會讓專案難以在不引發連鎖反應的情況下增加功能。最後新的功能引入 Bug，從而導致另一個 Bug，然後一個接著一個，這樣的事情不斷發生。 在  沒有做過可擴展性設計的程式碼  上進行擴展功能，常常是火上加油！ 那為什麼不把程式「設計」成可擴展就好了呢？ 開發者知識普遍不足 一個充滿外行人的產業 開發者們來自不同的背景，且有大量不同的方式去解決問題，但是一個開發者應該具備什麼樣的知識體系，並沒有一個廣泛的共識。 更不幸的是，許多開發者在學校裡面學到的知識是過時的，學校提供的程式設計課程並未給學生做好準備。這些課程通常只關注程式語言的功能，但是 ... 掌握一門程式語言並不能使你成為軟體開發者，正如掌握一門自然語言並不能使你成為作家 學校所教的知識，並不是大部分軟體開發者的工作內容。 開發者也許能編寫一個可運行的程式碼，但若要 回頭去擴展程式碼卻 常 常 是艱難且冒險的 。 軟體開發過程中，開發者需要做出無數個選擇，加上每個開發者用不同的方法解決問題，助長了難以維護、難以擴展的程式碼。最終讓  系統設計的思想溝通  變得困難（ 工程師必須花費大量時間閱讀程式碼 ）。 不論是開發者還是管理者都需要對  軟體複雜的本質  做管理。為了編寫出更容易應對變化的程式碼，我們必須填補基礎認知方面的空白。 導入設計原則 若有一些