定義：一個軟體實體如類、子產品和函數應該對擴充開放，對修改關閉。
問題由來：在軟體的生命周期内，因為變化、更新和維護等原因需要對軟體原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，并且需要原有代碼經過重新測試。
解決方案：當軟體需要變化時，盡量通過擴充軟體實體的行為來實作變化，而不是通過修改已有的代碼來實作變化。
開閉原則是面向對象設計中最基礎的設計原則，它指導我們如何建立穩定靈活的系統。開閉原則可能是設計模式六項原則中定義最模糊的一個了，它隻告訴我們對擴充開放，對修改關閉，可是到底如何才能做到對擴充開放，對修改關閉，并沒有明确的告訴我們。以前，如果有人告訴我“你進行設計的時候一定要遵守開閉原則”，我會覺的他什麼都沒說，但貌似又什麼都說了。因為開閉原則真的太虛了。
在仔細思考以及仔細閱讀很多設計模式的文章後，終于對開閉原則有了一點認識。其實，我們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，隻要我們對前面5項原則遵守的好了，設計出的軟體自然是符合開閉原則的，這個開閉原則更像是前面五項原則遵守程度的“平均得分”，前面5項原則遵守的好，平均分自然就高，說明軟體設計開閉原則遵守的好；如果前面5項原則遵守的不好，則說明開閉原則遵守的不好。
其實筆者認為，開閉原則無非就是想表達這樣一層意思：用抽象建構架構，用實作擴充細節。因為抽象靈活性好，适應性廣，隻要抽象的合理，可以基本保持軟體架構的穩定。而軟體中易變的細節，我們用從抽象派生的實作類來進行擴充，當軟體需要發生變化時，我們隻需要根據需求重新派生一個實作類來擴充就可以了。當然前提是我們的抽象要合理，要對需求的變更有前瞻性和預見性才行。
說到這裡，再回想一下前面說的5項原則，恰恰是告訴我們用抽象建構架構，用實作擴充細節的注意事項而已：單一職責原則告訴我們實作類要職責單一；裡氏替換原則告訴我們不要破壞繼承體系；依賴倒置原則告訴我們要面向接口程式設計；接口隔離原則告訴我們在設計接口的時候要精簡單一；迪米特法則告訴我們要降低耦合。而開閉原則是總綱，他告訴我們要對擴充開放，對修改關閉。
最後說明一下如何去遵守這六個原則。對這六個原則的遵守并不是是和否的問題，而是多和少的問題，也就是說，我們一般不會說有沒有遵守，而是說遵守程度的多少。任何事都是過猶不及，設計模式的六個設計原則也是一樣，制定這六個原則的目的并不是要我們刻闆的遵守他們，而需要根據實際情況靈活運用。對他們的遵守程度隻要在一個合理的範圍内，就算是良好的設計。我們用一幅圖來說明一下。
圖中的每一條次元各代表一項原則，我們依據對這項原則的遵守程度在次元上畫一個點，則如果對這項原則遵守的合理的話，這個點應該落在紅色的同心圓内部；如果遵守的差，點将會在小圓内部；如果過度遵守，點将會落在大圓外部。一個良好的設計展現在圖中，應該是六個頂點都在同心圓中的六邊形。
