開閉原則很簡單，一句話：“Closed for Modification; Open for Extension”——“對變更關閉；對擴展開放”。開閉原則其實沒什么好講的，我將其歸結為一個高層次的設計總則。就這一點來講，OCP的地位應該比SRP優先。
OCP的動機很簡單：軟件是變化的。不論是優質的設計還是低劣的設計都無法回避這一問題。OCP說明了軟件設計應該盡可能地使架構穩定而又容易滿足不同的需求。
為什么要OCP？答案也很簡單——重用。
“重用”，并不是什么軟件工程的專業詞匯，它是工程界所共用的詞匯。早在軟件出現前，工程師們就在實踐“重用”了。比如機械產品，通過零部件的組裝得到最終的能夠使用的工具。由于機械部件的設計和制造過程是極其復雜的，所以互換性是一個重要的特性。一輛車可以用不同的發動機、不同的變速箱、不同的輪胎……很多東西我們直接買來裝上就可以了。這也是一個OCP的例子。（可能是由于我是搞機械出身的吧，所以就舉些機械方面的例子^_^）。
如何在OO中引入OCP原則？把對實體的依賴改為對抽象的依賴就行了。下面的例子說明了這個過程：
05賽季的時候，一輛F1賽車有一臺V10引擎。但是到了06賽季，國際汽聯修改了規則，一輛F1賽車只能安裝一臺V8引擎。車隊很快投入了新賽車的研發，不幸的是，從工程師那里得到消息，舊車身的設計不能夠裝進新研發的引擎。我們不得不為新的引擎重新打造車身，于是一輛新的賽車誕生了。但是，麻煩的事接踵而來，國際汽聯頻頻修改規則，搞得設計師在“賽車”上改了又改，最終變得不成樣子，只能把它廢棄。
為了能夠重用這輛昂貴的賽車，工程師們提出了解決方案：首先，在車身的設計上預留出安裝引擎的位置和管線。然后，根據這些設計好的規范設計引擎（或是引擎的適配器）。于是，新的賽車設計方案就這樣誕生了。
顯然，通過重構，這里應用的是一個典型的Bridge模式。這個實現的關鍵之處在于我們預先給引擎留出了位置！我們不必因為對引擎的規則的頻頻變更而制造相當多的車身，而是盡可能地沿用和改良現有的車身。
說到這里，想說一說OO設計的一個誤區。
學習OO語言的時候，為了能夠說明“繼承”（或者說“is-a”）這個概念，教科書上經常用實際生活中的例子來解釋。比如汽車是車，電車是車，F1賽車是汽車，所以車是汽車、電車、F1賽車的上層抽象。這個例子并沒有錯。問題是，這樣的例子過于“形象”了！如果OO設計直接就可以將現實生活中的概念引用過來，那也就不需要什么軟件工程師了！OO設計的關鍵概念是抽象。如果沒有抽象，那所有的軟件工程師的努力都是徒勞的。因為如果沒有抽象，我們只能去構造世界中每一個對象。上面這個例子中，我們應該看到“引擎”這個抽象的存在，因為車隊的工程師們為它預留了位置，為它制定了設計規范。
上面這個設計也實現了后面要說的DIP（依賴倒置原則）。但是請記住，OCP是OO設計原則中高層次的原則，其余的原則對OCP提供了不同程度的支持。為了實現OCP，我們會自覺或者不自覺地用到其它原則或是諸如Bridge、Decorator等設計模式。然而，對于一個應用系統而言，實現OCP并不是設計目的，我們所希望的只是一個穩定的架構。所以對OCP的追求也應該適可而止，不要陷入過渡設計。正如Martin本人所說：“No significant program can be 100% closed.”“Closure not complete but strategic”
（下一篇就要講LSP了，我覺得這是意義最為重要的OO設計原則，它直指當今主流OO語言的軟肋，點出了OO設計的精髓。）