狹義理解：對擴展開發，對修改封閉

在學習設計模式之前，應該先對軟件設計原則有一定的了解，設計模式在一定程度上是迎合軟件設計原則而產生的，脫離了軟件設計原則，設計模式是沒有意義的。

開-閉原則(Open-Closed Principle, OCP)

1.什么是開閉原則

1988年，Bertrand Meyer在他的著作《Object Oriented Software Construction》中提出了開閉原則，它的原文是這樣：“Software entities should be open for extension,but closed for modification”。翻譯過來就是：“軟件實體應當對擴展開放，對修改關閉”。這句話說得略微有點專業，我們把它講得更通俗一點，也就是：軟件系統中包含的各種組件，例如模塊（Modules）、類（Classes）以及功能（Functions）等等，應該在不修改現有代碼的基礎上，引入新功能。開閉原則中“開”，是指對于組件功能的擴展是開放的，是允許對其進行功能擴展的；開閉原則中“閉”，是指對于原有代碼的修改是封閉的，即不應該修改原有的代碼。

2.如何實現開閉原則

實現開閉原則的關鍵就在于“抽象”。把系統的所有可能的行為抽象成一個抽象底層，這個抽象底層規定出所有的具體實現必須提供的方法的特征。作為系統設計的抽象層，要預見所有可能的擴展，從而使得在任何擴展情況下，系統的抽象底層不需修改；同時，由于可以從抽象底層導出一個或多個新的具體實現，可以改變系統的行為，因此系統設計對擴展是開放的。

我們在軟件開發的過程中，一直都是提倡需求導向的。這就要求我們在設計的時候，要非常清楚地了解用戶需求，判斷需求中包含的可能的變化，從而明確在什么情況下使用開閉原則。

關于系統可變的部分，還有一個更具體的原則是對可變性的封裝原則（Principle of Encapsulation of Variation,? EVP），它從軟件工程實現的角度對開閉原則進行了進一步的解釋。EVP要求在做系統設計的時候，對系統所有可能發生變化的部分進行評估和分類，每一個可變的因素都單獨進行封裝。“對可變性的封裝原則”意味著兩點：

（1）一種可變性不應當散落在代碼的很多角落里，而應當被封裝到一個對象里面。同一種可變性的不同表象意味著同一個繼承等級結構中的具體子類，因此，我們可以期待在設計模式中看到繼承關系。繼承應當被看做是封裝變化的方法，而不應當被認為是從一般的對象生成特殊的對象的方法。

（2）一種可變性不應當與另一種可變性混合在一起。

我們在實際開發過程的設計開始階段，就要羅列出來系統所有可能的行為，并把這些行為加入到抽象底層，根本就是不可能的，這么去做也是不經濟的，費時費力。另外，在設計開始階段，對所有的可變因素進行預計和封裝也不太現實，也是很難做得到。所以，開閉原則描繪的愿景只是一種理想情況或是極端狀態，現實世界中是很難被完全實現的。我們只能在某些組件，在某種程度上符合開閉原則的要求。

通過以上的分析，對于開閉原則，我們可以得出這樣的結論：雖然我們不可能做到百分之百的封閉，但是在系統設計的時候，我們還是要盡量做到這一點。

對于軟件系統的功能擴展，我們可以通過繼承、重載或者委托等手段實現。以接口為例，它對修改就是是封閉的，而對具體的實現是開放的，我們可以根據實際的需要提供不同的實現，所以接口是符合開閉原則的。

3.開閉原則能夠帶來什么好處

如果一個軟件系統符合開閉原則的，那么從軟件工程的角度來看，它至少具有這樣的好處：

（1）可復用性好

我們可以在軟件完成以后，仍然可以對軟件進行擴展，加入新的功能，非常靈活。因此，這個軟件系統就可以通過不斷地增加新的組件，來滿足不斷變化的需求。

（2）可維護性好

由于對于已有的軟件系統的組件，特別是它的抽象底層不去修改，因此，我們不用擔心軟件系統中原有組件的穩定性，這就使變化中的軟件系統有一定的穩定性和延續性。

4.閉原則與其它原則的關系

開閉原則具有理想主義的色彩，它是面向對象設計的終極目標。因此，針對開閉原則的實現方法，一直都有面向對象設計的大師費盡心機，研究開閉原則的實現方式。其它原則和方法如：里氏代換原則（LSP）、依賴倒轉原則（DIP）、接口隔離原則（ISP）以及抽象類（Abstract Class）、接口(Interace)等等，都可以看作是開閉原則的實現方法。

此部分參考：http://www.cnblogs.com/wanghao72214/archive/2009/03/13/1410610.html

總結

以上是生活随笔為你收集整理的软件设计原则（一）开闭原则(Open-Closed Principle, OCP)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。