年前匆匆整理了一下SRP原則，即單一職責原則：SOLID軟件設計原則之SRP。趁着週末有時間，還一還之前欠下的債。
莊子《刻意》篇有云：“形勞而不休則弊，精用而不已則勞，勞則竭”。不停地忙碌容易讓人陷入疲倦，忘記爲何而出發，適當的閒暇纔是思想的溫牀，也爲更好地工作積蓄力量。在項目不是壓迫得特別緊張的情況下，週末真的更適合學習和思考，因爲有難得的獨處和安靜來梳理自己的思路。
言歸正傳。當我們還是初級開發者的時候，總是希望最好是一個軟件做完了就不要再來新的變更，內心裏對變化充滿了抗拒。但我們在設計任何系統的時候，如果一開始就指望需求確定後就不再變化，這在現實中是不大可能的，也不科學。軟件開發沒有一勞永逸的事，不管我們情不情願，以開放的心態看待變化的世界是每一個開發者應該具備的素質。
顯然，一套未經良好設計的軟件，面對較大需求變更的時候往往需要推倒重來，這顯然需要付出相當大的成本和代價。既然需求一定會發生變化，那麼怎樣做設計才能在面對需求變化時，以最小的代價實現既定的目標呢？OCP原則給了我們答案。
OCP原則即Open Closed Principle, Software enities like classes, modules and functions should be open for extension but closed for modifications。也就是說，軟件實體(類、模塊、函數等等)應該對擴展開放，對修改關閉。
對於一個軟件實體來說，絕對的對修改關閉是不可能的。無論一個模塊多麼“封閉”，都有可能存在一些無法與之兼容的變化。既然不可能完全封閉，設計者在設計階段必須能夠儘可能地設想出未來可能發生的變化，以及可以不變的部分，將不變的部分封閉起來，而對變化的部分，則通過構造抽象來將其隔離。
打個比方，一家小公司最初只有20個研發人員，這些研發人員採用統一的薪酬管理方法，薪酬系統裏只有一種計薪模式，假如是基本工資+獎金。隨着公司業務的發展，公司漸漸成立了人事部(基本工資)、銷售部(底薪+提成)，等等。每一個部門的計薪方式可能有所不同，那麼薪酬管理軟件如何設計呢？每增加一種計薪方式就去修改原有的算法顯然是低效的，而且容易影響到原本穩定的計薪方式。合理的做法是，將計薪功能抽象出來，當有新的計薪模式來的時候，只需要添加新的算法類即可，而不需要改動原有穩定的算法。合理的設計如下圖。假如將來要再增加一個售後部門的計薪方式，那麼只需增加一個售後薪酬算法類即可。
OCP原則是面向對象設計的核心所在。遵循這個原則可以帶來面向對象技術所聲稱的可維護、可擴展、可複用以及良好的靈活性等特點。但必須要注意的是，合理抽象非常重要，只需對系統中可能出現頻繁變化的部分進行抽象，避免過度抽象。