原則內容：OCP原則就是"開-閉原則"，一個軟件應該對擴展開放，對修改關閉。
解釋 ：在設計一個模塊的時候，應當使得這個模塊可以在不被修改的前提下面被擴展。換言之，應該可以在不必修改源代碼的情況下改變這個
模塊的行為。這個原則有2點要求：
×：擴展開放
×：關閉修改
滿足OCP原則系統的優點：
×：通過擴展已有的軟件系統，提供新的行為，可以使得軟件系統滿足新需求
×：已有的軟件模塊，特別是重要的抽象層模塊不能做變更，這使得變化中的軟件系統有一定的穩定性和延續性。
如何實現OCP原則：
1、抽象是關鍵。
   對需要設計的系統進行抽象，在此前提下面，讓抽象的實現機制千變萬化。這個抽象層必須預見到所有的可能的擴展，任何實現的改變都不會改變該抽象結構。這樣使得系統的抽象層無需修改，從而滿足OCP原則的第二條－關閉修改。
2、對可變性的封裝原則
   OCP從另一個角度來說，就是EVP(principle of Encapsulation Variation)原則。即找到系統的可變因素，將之封裝起來。這個原則意味著2點：
×：一種可變性不應當散落在代碼的很多角落里，而應當被封裝到一個對象里面。繼承應當被看    做是封裝變化的方法，而不應當被認為是從一般的對象生成特殊的對象方法。
×：一種可變性不應當與另一種可變性混合在一起。所有的類圖的繼承結構一般不會超過兩層，不然就意味著將兩種不同的可變性混合在一起。
與其他設計原則的關系
LSP原則：這個原則是說任何基類出現的地方，子類一定可以出現。
這個原則是對OCP原則的補充，基類和子類的關系就是抽象化的具體體現，所以LSP原則是對實現抽象化的具體步驟的規范。一般來說，違背了LSP原則，一定違反了OCP原則，反之不一定成立。
CARP原則：這個原則講的是要盡可能的多用合成/聚合，而不是繼承關系達到復用的目的。
CARP原則和LSP原則相輔相成。二者都是對實現OCP原則的具體步驟的規范。前者要求設計師首先考慮合成/聚合關系；后者要求在使用繼承關系的時候， 必須確定這個關系是符合一定條件的。CARP原則是OCP原則的必要條件，違反了這個原則，就無法使系統實現OCP原則這個目標。
DIP原則：這個原則是說要依賴于抽象，不要依賴于實現。
DIP原則和OCP原則是目標和手段的關系。OCP是目標，DIP是手段。要想實現OCP原則，必須堅持DIP原則。違反了DIP原則，則不可能達到OCP原則要求。

LoD原則：這個原則講的是一個軟件實體應該盡可能少的和其他實體發生作用。
當一個system面臨功能擴展的時候，其中會有一些模塊，他們需要修改的壓力比其他的模塊要大一些，如果這些模塊是相對孤立的，那么他們就不會將修改的 壓力傳遞給其他模塊。根據LoD原則設計的系統，在功能需要擴展的時候，會相對容易的做到對修改的關閉。LoD原則是一條通向OCP原則的道路。
ISP原則：這個原則是說，應當為客戶端提供盡可能小的單獨接口，而不要提供大的總接口。ISP原則和LoD原則講的都是一個軟件實體與另一個軟件實體的通訊限制。廣義的LoD原則要求盡可能限制通訊的寬度和深度，ISP原則所限制的是通信寬度。
一個重構方法的討論
“將條件轉移語句改寫成為多態性”是一條廣為流傳的代碼重構做法。

這一做法本身并不能保證“開-閉”原則，應當以“開-閉”原則判斷是否需要改寫成多態。條件轉移并不是錯誤，如果需要，完全可以選擇使用條件轉移。

如果一個條件轉移語句確實封裝了某種商務邏輯的可變性，那么將此種可變性封裝起來就符合“開-閉”原則設計思想了。如果一個條件轉移語句沒有涉及重 要的商務邏輯，或者不會隨著時間的變化而變化，也不意味著任何的可擴展性，那么它就沒有涉及任何有意義的可變性。這時候將這個條件轉移語句改寫成多態性就 是一種沒有意義的浪費。
抽象類應當擁有盡可能多的共同代碼

 在一個繼承的等級結構中，共同的代碼應當盡量向等級結構的上方移動。把重復的代碼從子類里面移動到超類里面，可以提高代碼的復用率。在代碼發生改變時，設計師之需要修改一個地方。

抽象類應當擁有盡可能少的數據

與代碼的移動方向相反，數據的移動方向是從抽象類到具體類，向等級結構的下方移動。一個對象的數據不論是否使用都會占用資源，所以應當放到等級結構的低端。

 

什么時候才應當使用繼承復用

1．子類是超類的一個特殊種類，而不是超類的一個角色，Is-A才符合繼承關系。

2．永遠不會出現需要將子類換成另一個類的子類的情況。

3．子類具有擴展超類的責任，而不是具有置換掉（Override）和注銷掉（Nullify）超類的責任。

4．只有在分類學角度上有意義時，才可以使用繼承，不要從工具類繼承。