【編程哲學：Open-Closed Principle】 試想像公司計劃將一個內部系統變成 SaaS 向其他公司銷售，而我們必須為每間公司提供一些功能的定製。我們應該如何建構系統以符合客戶要求，同時可以進行有效率的持續交付（例如大規模的錯誤修復）？最簡單的策略一定的利用 git branch 為不同的公司修改，但這明顯沒有擴展性，只適用於小規模的定製。而這正是一個能應用Open-Closed Principle的場景。 開放-封閉原則是物件導向設計中 SOLID 原則之一，但不僅限於OOP。它的核心思想是「模組應該對擴展開放，對修改封閉」。這意味著軟體系統的設計應該允許在不改變現有程式碼的情況下，透過新增程式碼來擴展功能，從而提高系統的可維護性和靈活性。 在上述的情況，我們應該為系統定義可定製的範圍，然後建立抽象來為功能提供彈性。建立抽象的方法有很多，可以是不同的設計模式，也可以是定義環境變數來控制功能。（e.g. feature flag）。而這個原則的重點是減少代碼的修改，而不是大型重構的理由。所有原則都是解決現實問題，而不應執著只於原則的實踐。