「開閉原則」
--對修改關閉，對擴充套件開放。在設計模式中的解釋是這樣的：「在軟體設計開發中，不要對原有的**進行修改，通過對原有**進行擴充套件來實現相應功能。」
初學模式，這段話讀著絕對拗口，甚至是矛盾重重。不修改，怎麼去擴充套件呢？
其實，在盡量不修改**的情況下進行擴充套件是可行的的，注意，這裡是「盡量」。官方的解釋中好像沒發現有這個詞的，因為如果較真的話，在不修改一點**的情況下，根本無法實現擴充套件的。
下面，我們大家熟悉的「抽象」概念實現入手，看一下如何實現「開閉」。
在物件導向語言中，抽象類是乙個比較常用的東西，那麼，我們何時需要用到抽象類？用它來做什麼？
從表象上來看，一般抽象類會有一些實現了的方法，還有一些沒有實現的方法。只有繼承了抽象類，並實現了抽象類沒有實現的方法之後
,才能使用。那麼，這和開閉原則，又有啥關係呢。
抽象類中已經實現了的方法，理論上說不應該再被修改了，這就對應著開閉原則中的「對修改關閉」。
繼承於某抽象類後，必須要實現抽象類沒有實現的抽象方法，這可以理解為對抽象類進行了「擴充套件」。即：對與抽象類來說，我們一般不修改已經實現的方法，但需要對抽象方法進行實現（即擴充套件）。這就是開閉原則的一種體現。
在設計開發中，為什麼要實現開閉原則呢？
我覺得開閉原則的好處主要在於下面兩個方面：
1 在設計初期，對需求進行好好地分析，考慮周全之後，設計出乙個系統核心，這個核心，這個核心是整個系統最重要的部分，在未來應該是極難發生變化的（需要變化的東西我們將其做成抽象的，以便以後擴充套件和和替換）。這樣增加系統的穩定性。
2 在以後的開發或者維護中，如果當前的系統不能夠滿足需要，我們可以通過對可擴充套件部分的修改，賦予系統新的生命力，卻不破壞整體結構。
由上來看，要很好的滿足開閉原則，主要在於前期的設計階段。
有人也許會問，我的前期設計可能就是沒能夠考慮的很周全，導致了錯誤的設計，或者客戶對原有的需求提出了很大的改動，這時怎麼辦？
這種情況有一定的發生可能，不管什麼原因造成的，在一開始就錯了，所以一步錯、步步錯。那麼這種情況就真的一點都沒法補救了嗎？我認為不是，參考一下其他的模式，我們也許會想出一種比較周全的修改方式。
個人感覺開閉原則在整個設計模式中非常的重要，彷彿其他的設計模式都是應其而生、為其而活的。就算不懂得具體的設計模式方法，只要能夠深刻的理解這個概念，那麼對模式的理解已經比較深刻了，也許寫不出很符合模式範例的模式**，但相信會比死搬硬套好的多。這也許就像武俠中的無招勝有招吧。
ps:其實在生活中，開閉原則也存在於我們身邊，比如在國家的改革改革過程中，如何進行破與立；在為人處事中，如何堅持自己的原則和適應社會等等，都是開閉原則的體現。有時候真感覺模式是一種哲學，值得大家深入研究**的。
Java與模式 「開 閉」原則
開 閉 原則講的是 乙個軟體實休應當對擴充套件開放，對修改關閉，這一原則最早同bertrand meyer提出，英文原文是 software entities should be open for extension,but closed for modification.這個原則所說是，在設計乙個...
設計模式 開閉原則
開閉原則的核心是 對擴充套件開放，對修改關閉 白話意思就是我們改變乙個軟體時 比如擴充套件其他功能 應該通過擴充套件的方式來達到軟體的改變，而不應愛修改原有 來實現變化 軟體系統中包含的各種元件，例如模組 modules 類 classes 以及功能 functions 等等，應該在不修改現有 的基...
設計模式 開閉原則
設計模式 開閉原則 即 對立與統一原則 軟體實體應該對擴充套件開放，對修改關閉，即實體應當通過擴充套件實現變化，而不是修改 實現變化 什麼是軟體實體，專案或軟體中按照一定邏輯規劃劃分的模組 抽象 類 方法書店銷售書籍 然後書寫 如下 書籍介面 public inte ce ibook 書店 類書籍，...