【設計模式六大原則】開閉原則

定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。

問題由來：在軟件的生命週期內，由於變化、升級和維護等緣由須要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使咱們不得不對整個功能進行重構，而且須要原有代碼通過從新測試。

解決方案：當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。

開閉原則是面向對象設計中最基礎的設計原則，它指導咱們如何創建穩定靈活的系統。開閉原則多是設計模式六項原則中定義最模糊的一個了，它只告訴咱們對擴展開放，對修改關閉，但是到底如何才能作到對擴展開放，對修改關閉，並無明確的告訴咱們。之前，若是有人告訴我「你進行設計的時候必定要遵照開閉原則」，我會覺的他什麼都沒說，但貌似又什麼都說了。由於開閉原則真的太虛了。

在仔細思考以及仔細閱讀不少設計模式的文章後，終於對開閉原則有了一點認識。其實，咱們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要咱們對前面5項原則遵照的好了，設計出的軟件天然是符合開閉原則的，這個開閉原則更像是前面五項原則遵照程度的「平均得分」，前面5項原則遵照的好，平均分天然就高，說明軟件設計開閉原則遵照的好；若是前面5項原則遵照的很差，則說明開閉原則遵照的很差。

其實筆者認爲，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。由於抽象靈活性好，適應性廣，只要抽象的合理，能夠基本保持軟件架構的穩定。而軟件中易變的細節，咱們用從抽象派生的實現類來進行擴展，當軟件須要發生變化時，咱們只須要根據需求從新派生一個實現類來擴展就能夠了。固然前提是咱們的抽象要合理，要對需求的變動有前瞻性和預見性才行。

說到這裏，再回想一下前面說的5項原則，偏偏是告訴咱們用抽象構建框架，用實現擴展細節的注意事項而已：單一職責原則告訴咱們實現類要職責單一；里氏替換原則告訴咱們不要破壞繼承體系；依賴倒置原則告訴咱們要面向接口編程；接口隔離原則告訴咱們在設計接口的時候要精簡單一；迪米特法則告訴咱們要下降耦合。而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。

最後說明一下如何去遵照這六個原則。對這六個原則的遵照並非是和否的問題，而是多和少的問題，也就是說，咱們通常不會說有沒有遵照，而是說遵照程度的多少。任何事都是過猶不及，設計模式的六個設計原則也是同樣，制定這六個原則的目的並非要咱們刻板的遵照他們，而須要根據實際狀況靈活運用。對他們的遵照程度只要在一個合理的範圍內，就算是良好的設計。咱們用一幅圖來講明一下。

 

圖中的每一條維度各表明一項原則，咱們依據對這項原則的遵照程度在維度上畫一個點，則若是對這項原則遵照的合理的話，這個點應該落在紅色的同心圓內部；若是遵照的差，點將會在小圓內部；若是過分遵照，點將會落在大圓外部。一個良好的設計體如今圖中，應該是六個頂點都在同心圓中的六邊形。

在上圖中，設計一、設計2屬於良好的設計，他們對六項原則的遵照程度都在合理的範圍內；設計三、設計4設計雖然有些不足，但也基本能夠接受；設計5則嚴重不足，對各項原則都沒有很好的遵照；而設計6則遵照過渡了，設計5和設計6都是迫切須要重構的設計。

到這裏，設計模式的六大原則就寫完了。主要參考書籍有《設計模式》《設計模式之禪》《大話設計模式》以及網上一些零散的文章，但主要內容主要仍是我本人對這六個原則的感悟。寫出來的目的一方面是對這六項原則系統地整理一下，一方面也與廣大的網友分享，由於設計模式對編程人員來講，的確很是重要。正若有句話叫作一千個讀者眼中有一千個哈姆雷特，若是你們對這六項原則的理解跟我有所不一樣，歡迎留言，你們共同探討。