你有沒有遇過這樣的情況？當你設計一個系統時，一開始覺得一切順利，結果過了不久，客戶突然要求增加新功能。問題來了，每次改需求，你的程式碼都變得一團混亂，越改越多錯誤，最後讓你崩潰了。 軟體開發中需求變動是常態，但每次修改都得動到核心程式碼，難免會增加出錯的風險，也讓開發效率大打折扣。今天就要來聊聊「開放封閉原則」（Open-Closed Principle，簡稱 OCP）了。 開放封閉原則是什麼？ 簡單來說，這個原則提倡「對擴展開放，對修改封閉」。意思就是當你要新增功能時，不應該去動到原本的程式碼，而是應該用擴展的方式來解決問題。這樣既能避免弄壞現有的功能，也能快速滿足新的需求。 舉個簡單的例子 想像你設計了一個程式，可以畫圖形。一開始只要支援圓形和方形，你的程式運作得很順利。但當客戶要你增加三角形、橢圓形時，你發現每次都要去修改程式碼，甚至得加入更多「如果是這個形狀就畫這樣」的條件。當圖形種類越來越多，程式就變得非常難以維護了。 這樣的做法違反了開放封閉原則，因為每次有新需求，都得去修改原本的邏輯，這樣增加了出錯的風險，也讓系統越來越複雜。 正確的設計應該怎麼做？ 按照 OCP，我們應該設計一個架構，讓每種圖形有自己的「畫圖邏輯」。這樣一來當客戶要你新增三角形時，你只需要增加一個「三角形」的類別，不需要去動到畫圖的核心邏輯。這樣既符合 OCP，又讓系統變得更靈活。 為什麼要這麼麻煩？ 開放封閉原則的好處在於「系統的穩定性與可擴展性」。當你能在不改動現有程式碼的情況下擴展功能，就能減少錯誤風險，保護現有的系統穩定運作。隨著系統變得越來越複雜，這種設計方式可以幫助你更好地維護程式。 總結一下，OCP 就像一個「保障」，讓你面對需求變更時，能更輕鬆地應對，也不用擔心把原本好好的功能弄壞。特別是在應對頻繁變更的需求時，這種設計原則的優勢會顯現得更為明顯。
設計原則的魅力在哪？參考我今年在iThome鐵人賽寫的文章吧。
https://ithelp.ithome.com.tw/articles/10354752
