發表文章

目前顯示的是有「S.O.L.I.D原則」標籤的文章

物件導向設計原則:里氏替換原則,定義、解析

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

物件導向設計原則:開放封閉原則,定義、解析與實踐

圖片
系列文章 淺談物件導向 SOLID 原則對工程師的好處與如何影響能力 再談 SOLID 原則,Why SOLID? SRP 單一職責原則,定義、解析與實踐 物件導向設計原則:開放封閉原則,定義、解析與實踐 開放封閉原則(Open-Closed Principle) 定義: Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. -- 軟體中的類別、模組、函式等等應該開放擴充,但是封閉修改。 白話版本為: 當系統需要擴充功能時,應該藉由 增加新的程式碼 來擴充系統的功能,而 不是藉由修改原本已經存在的程式碼 來擴充系統的功能。 開放封閉原則為軟體開發的 首要原則 ,很多軟體開發原則都是建構在這短短一句話之上,因此可以通過此原則引伸出其他原則。很多時候一個程式具有良好的設計,往往說明它是符合開放封閉原則。 目的 隔離業務邏輯與附加邏輯,使業務邏輯更易於擴充,以便因應需求變化。 解析 什麼是業務邏輯?附加邏輯? 一個系統總有幾個極具價值的核心邏輯,這些核心邏輯實現了企業或專案的業務規則(Business Rule)與 Know How。通常可以從核心邏輯延伸出更多功能,提供使用者的便利性,以下將這些核心業務邏輯簡稱為「業務邏輯」。也就是說系統中有可能 20% 是業務邏輯 ,剩下的 80% 是圍繞著業務邏輯延伸出來的附加邏輯 。 舉例來說,一個診所掛號系統一開始只有「掛號與叫號」功能。但若需要的話,也可以延伸出「叫號時發送簡訊提醒患者」功能。掛號系統的案例中 業務邏輯 是「掛號與叫號」;而「叫號時發送簡訊提醒患者」則是 隨著時間與新需求延伸出來的附加邏輯 。 為什麼要隔離 業務邏輯 與 附加邏輯? 和軟體複雜的特質 軟體熵(Software entropy) 有關,指系統在經過修改後,程式碼的無序程度(意圖流失程度)與複雜程度皆會上昇。 需求變更和除錯是系統修改的主因,系統會隨著時間不斷衍生出新需求。這些需求可能是工程浩大的新功能;也可能是為了某個特定案例只使用一次的需求。甚至客戶往往在看見實際功能後,才想