我個人覺得將 開放封閉原則 放在第二個說明真的不是那麼的恰當，
主要的原因是開放封閉原則是一個大的準則，並沒有一個比較實際的規範。

定義

Software entities (classes, modules, functions, etc.) should be open for extension,
but closed for modification.

這段用比較不精準的翻譯成白話文的意思大概是說:
驗收後的程式碼不要改，請寫新的類別(Class)來處理新需求

這段話在原文的定義中並沒說到如何實踐，也沒有明說怎樣叫做不要修改程式碼。
對於剛接觸的人來說，其實並不是那麼好理解。
所以我們這邊暫時先暫時可以先理解為透過開發中遵循 單一職責原則(SRP) 和 依賴倒轉原則(DIP)
可以符合開放封閉原則(OCP)

用途

開發上我們經常發現用戶的需求總是隨著時間的推移不斷的變化，
當我們開發中不斷地修改原本的類別(Class)時，久了容易造成結構鬆散，或是發生非預期的錯誤。
所以我們可以透過對類別的抽象化的方式來達成不改變原程式，又能新增功能的效果。

結語

符合開放封閉原則(OCP)主要有兩個特點

• 減少耦合
• 增加擴展性

基於這兩個特點在開發上我們就能更容易的對程式做維護。
不需要擔心，對於某些部分的修改會影響到其他的功能。

可能會有小夥伴問我這次怎麼沒有寫範例程式。
主要原因是這SOLID是原則而不是設計方式。
既然是系列文，那我們就盡量每篇都抓住固定的重點，
之後我們會在設計模式上更詳盡的說明怎麼去遵守五大原則。