系列文章 淺談物件導向 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) 有關，指系統在經過修改後，程式碼的無序程度(意圖流失程度)與複雜程度皆會上昇。 需求變更和除錯是系統修改的主因，系統會隨著時間不斷衍生出新需求。這些需求可能是工程浩大的新功能；也可能是為了某個特定案例只使用一次的需求。甚至客戶往往在看見實際功能後，才想
