本文同步更新於blog

Open-Close Principle (OCP)

A software artifact should be open for extension but closed for modification.

一個軟體製品應該對於擴展是開放的，但對於修改是封閉的。

OCP是系統架構背後的推動力之一。
目標是使系統易於擴展而不會因修改而產生較大的影響。

問：遵守單一職責原則會有什麼好處？
答：你就可以遵守開放封閉原則囉（笑）

職責拆分與抽象化，便是這個原則的核心精神。
其影響力無遠弗屆，從模組、類別到方法都能見其身影。

當你因為需求變更而修改到既有程式碼時，很有可能就會違反OCP。
（比違反SRP容易察覺）

這是之前，在S.O.L.I.D裡面比較困惑的原則，
實務情境不知道該如何遵守OCP。

目前理解的流程：

1. 先清楚各個程式碼區塊，所負責的任務是什麼。
2. 接著拆分職責，定義抽象的介面。
3. 最後考慮架構，理解何時可以修改既有程式碼、何時應該新增程式碼。

SRP跟OCP是我心中最重要的兩個原則，
相比之下，其他原則都像是他倆的補充說明。

ʕ •ᴥ•ʔ：定義好各個程式碼區塊的職責，然後遵守它。