架構師之路(6)---OOD的開閉原則 王澤賓

2 開閉原則（Open-Closed Principle,OCP）

2.1 什麼是開閉原則
    開閉原則是面向對象設計中「可複用設計」的基石，是面向對象設計中最重要的原則之一，其它不少的設計原則都是實現開閉原則的一種手段。

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

2.2 如何實現開閉原則
    實現開閉原則的關鍵就在於「抽象」。把系統的全部可能的行爲抽象成一個抽象底層，這個抽象底層規定出全部的具體實現必須提供的方法的特徵。做爲系統設計的抽象層，要預見全部可能的擴展，從而使得在任何擴展狀況下，系統的抽象底層不需修改；同時，因爲能夠從抽象底層導出一個或多個新的具體實現，能夠改變系統的行爲，所以系統設計對擴展是開放的。

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

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

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

    經過以上的分析，對於開閉原則，咱們能夠得出這樣的結論：雖然咱們不可能作到百分之百的封閉，可是在系統設計的時候，咱們仍是要儘可能作到這一點。
    對於軟件系統的功能擴展，咱們能夠經過繼承、重載或者委託等手段實現。以接口爲例，它對修改就是是封閉的，而對具體的實現是開放的，咱們能夠根據實際的須要提供不一樣的實現，因此接口是符合開閉原則的。

2.3 開閉原則可以帶來什麼好處
    若是一個軟件系統符合開閉原則的，那麼從軟件工程的角度來看，它至少具備這樣的好處：

  可複用性好。

    咱們能夠在軟件完成之後，仍然能夠對軟件進行擴展，加入新的功能，很是靈活。所以，這個軟件系統就能夠經過不斷地增長新的組件，來知足不斷變化的需求。

  可維護性好。

    因爲對於已有的軟件系統的組件，特別是它的抽象底層不去修改，所以，咱們不用擔憂軟件系統中原有組件的穩定性，這就使變化中的軟件系統有必定的穩定性和延續性。

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