發表文章

目前顯示的是有「重構」標籤的文章

2019 回顧工作與學習歷程

圖片
2019 回顧前言 2019 年可以說是既充實又偷懶的一年。為什麼呢?因為花了很多時間在學習理論知識,包含:重構、整潔架構、單元測試、領域驅動開發、行為驅動開發 …等等。雖然每個知識看起來像是完全獨立的領域,但對 2019 的我來說,它們都是應付 Legacy Application 的利器。 為什麼又說偷懶?部落格和作品幾乎停擺!學習知識理論不像學習新技術,能把應用新技術的步驟分享到部落格上。因為理論知識必須經過堆疊和內化才能在真實專案中落地實踐。再加上這一年很 榮幸受邀到高雄科技大學,帶領一批資工系的學生學習 PHP 式設計課程 ,備課與上課的時間幾乎吃掉了三個月的休閒時間,也就是平常能用來自學或練習的時間 …

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

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