定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
問題由來：在軟件的生命週期內，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。
解決方案：當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。
開閉原則是面向對象設計中最基礎的設計原則，它指導我們如何建立穩定靈活的系統。開閉原則可能是設計模式六項原則中定義最模糊的一個了，它只告訴我們對擴展開放，對修改關閉，可是到底如何才能做到對擴展開放，對修改關閉，並沒有明確的告訴我們。以前，如果有人告訴我“你進行設計的時候一定要遵守開閉原則”，我會覺的他什麼都沒說，但貌似又什麼都說了。因為開閉原則真的太虛了。
在仔細思考以及仔細閱讀很多設計模式的文章後，終於對開閉原則有了一點認識。其實，我們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要我們對前面5項原則遵守的好了，設計出的軟件自然是符合開閉原則的，這個開閉原則更像是前面五項原則遵守程度的“平均得分”，前面5項原則遵守的好，平均分自然就高，說明軟件設計開閉原則遵守的好；如果前面5項原則遵守的不好，則說明開閉原則遵守的不好。
其實筆者認為，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。因為抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟件架構的穩定。而軟件中易變的細節，我們用從抽象派生的實現類來進行擴展，當軟件需要發生變化時，我們只需要根據需求重新派生一個實現類來擴展就可以了。當然前提是我們的抽像要合理，要對需求的變更有前瞻性和預見性才行。
在開閉原則的定義中，軟件實體可以指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類。
任何軟件都需要面臨一個很重要的問題，即它們的需求會隨時間的推移而發生變化。當軟件系統需要面對新的需求時，我們應該盡量保證系統的設計框架是穩定的。如果一個軟件設計符合開閉原則，那麼可以非常方便地對系統進行擴展，而且在擴展時無須修改現有代碼，使得軟件系統在擁有適應性和靈活性的同時具備較好的穩定性和延續性。隨著軟件規模越來越大，軟件壽命越來越長，軟件維護成本越來越高，設計滿足開閉原則的軟件系統也變得越來越重要。
為了滿足開閉原則，需要對系統進行抽象化設計，抽象化是開閉原則的關鍵。在Java、C#等編程語言中，可以為系統定義一個相對穩定的抽象層，而將不同的實現行為移至具體的實現層中完成。在很多面向對象編程語言中都提供了接口、抽像類等機制，可以通過它們定義系統的抽象層，再通過具體類來進行擴展。如果需要修改系統的行為，無須對抽象層進行任何改動，只需要增加新的具體類來實現新的業務功能即可，實現在不修改已有代碼的基礎上擴展系統的功能，達到開閉原則的要求。
Sunny軟件公司開發的CRM系統可以顯示各種類型的圖表，如餅狀圖和柱狀圖等，為了支持多種圖表顯示方式，原始設計方案如下圖所示：
在ChartDisplay類的display()方法中存在如下代碼片段：
...... if (type.equals("pie")) { PieChart chart = new PieChart(); chart.display(); } else if (type.equals("bar")) { BarChart chart = new BarChart(); chart.display(); } ......在該代碼中，如果需要增加一個新的圖表類，如折線圖LineChart，則需要修改ChartDisplay類的display()方法的源代碼，增加新的判斷邏輯，違反了開閉原則。
現對該系統進行重構，使之符合開閉原則。
在本實例中，由於在ChartDisplay類的display()方法中針對每一個圖表類編程，因此增加新的圖表類不得不修改源代碼。可以通過抽象化的方式對系統進行重構，使之增加新的圖表類時無須修改源代碼，滿足開閉原則。具體做法如下：
(1) 增加一個抽像圖表類AbstractChart，將各種具體圖表類作為其子類；
(2) ChartDisplay類針對抽像圖表類進行編程，由客戶端來決定使用哪種具體圖表。
重構後結構如下圖所示：
在圖2中，我們引入了抽像圖表類AbstractChart，且ChartDisplay針對抽像圖表類進行編程，並通過setChart()方法由客戶端來設置實例化的具體圖表對象，在ChartDisplay的display()方法中調用chart對象的display()方法顯示圖表。如果需要增加一種新的圖表，如折線圖LineChart，只需要將LineChart也作為AbstractChart的子類，在客戶端向ChartDisplay中註入一個LineChart對象即可，無須修改現有類庫的源代碼。
注意：因為xml和properties等格式的配置文件是純文本文件，可以直接通過VI編輯器或記事本進行編輯，且無須編譯，因此在軟件開發中，一般不把對配置文件的修改認為是對系統源代碼的修改。如果一個系統在擴展時只涉及到修改配置文件，而原有的Java代碼或C#代碼沒有做任何修改，該系統即可認為是一個符合開閉原則的系統。