問題由來：在軟件的生命周期內，由於變化、升級和維護等原因須要對軟件原有代碼進行改動時，可能會給舊代碼中引入錯誤。也可能會使我們不得不正確整個功能進行重構，而且須要原有代碼經過又一次測試。
解決方式：當軟件須要變化時。盡量通過擴展軟件實體的行為來實現變化。而不是通過改動已有的代碼來實現變化。
開閉原則是面向對象設計中最基礎的設計原則。它指導我們怎樣建立穩定靈活的系統。開閉原則可能是設計模式六項原則中定義最模糊的一個了，它僅僅告訴我們對擴展開放，對改動關閉，但是究竟怎樣才干做到對擴展開放。對改動關閉，並沒有明白的告訴我們。
曾經，假設有人告訴我“你進行設計的時候一定要遵守開閉原則”。我會覺的他什么都沒說，但貌似又什么都說了。由於開閉原則真的太虛了。
在細致思考以及細致閱讀非常多設計模式的文章后，最終對開閉原則有了一點認識。
事實上。我們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，僅僅要我們對前面5項原則遵守的好了，設計出的軟件自然是符合開閉原則的。這個開閉原則更像是前面五項原則遵守程度的“平均得分”，前面5項原則遵守的好，平均分自然就高，說明軟件設計開閉原則遵守的好。假設前面5項原則遵守的不好。則說明開閉原則遵守的不好。
事實上筆者覺得。開閉原則無非就是想表達這樣一層意思：用抽象構建框架。用實現擴展細節。由於抽象靈活性好。適應性廣，僅僅要抽象的合理。能夠基本保持軟件架構的穩定。而軟件中易變的細節。我們用從抽象派生的實現類來進行擴展，當軟件須要發生變化時，我們僅僅須要依據需求又一次派生一個實現類來擴展就能夠了。當然前提是我們的抽象要合理，要對需求的變更有前瞻性和預見性才行。
講到這里，再回憶一下前面說的5項原則。恰恰是告訴我們用抽象構建框架。用實現擴展細節的注意事項而已：單一職責原則告訴我們實現類要職責單一；里氏替換原則告訴我們不要破壞繼承體系。依賴倒置原則告訴我們要面向接口編程。接口隔離原則告訴我們在設計接口的時候要精簡單一。迪米特法則告訴我們要減少耦合。
而開閉原則是總綱。他告訴我們要對擴展開放，對改動關閉。
最后說明一下怎樣去遵守這六個原則。
對這六個原則的遵守並非是和否的問題，而是多和少的問題，也就是說。我們一般不會說有沒有遵守，而是說遵守程度的多少。不論什么事都是過猶不及，設計模式的六個設計原則也是一樣，制定這六個原則的目的並非要我們刻板的遵守他們，而須要依據實際情況靈活運用。對他們的遵守程度僅僅要在一個合理的范圍內，就算是良好的設計。
我們用一幅圖來說明一下。
圖中的每一條維度各代表一項原則。我們根據對這項原則的遵守程度在維度上畫一個點。則假設對這項原則遵守的合理的話。這個點應該落在紅色的同心圓內部。假設遵守的差，點將會在小圓內部；假設過度遵守，點將會落在大圓外部。一個良好的設計體如今圖中，應該是六個頂點都在同心圓中的六邊形。
在上圖中，設計1、設計2屬於良好的設計。他們對六項原則的遵守程度都在合理的范圍內。設計3、設計4設計盡管有些不足，但也基本能夠接受；設計5則嚴重不足，對各項原則都沒有非常好的遵守；而設計6則遵守過渡了，設計5和設計6都是迫切須要重構的設計。
到這里，設計模式的六大原則就寫完了。主要參考書籍有《設計模式》《設計模式之禪》《大話設計模式》以及網上一些零散的文章。但主要內容主要還是我本人對這六個原則的感悟。
寫出來的目的一方面是對這六項原則系統地整理一下，一方面也與廣大的網友分享。由於設計模式對編程人員來說，的確很重要