“開-閉”原則 （Open-Closed principle, OCP）
一個軟件實體應當對擴展開放，對修改關閉。
Software entities should be open for extension, but closed for modification.
在設計一個模塊的時候，應當使這個模塊可以在不被修改的前提下被擴展。
“可變性的封裝原則”從工程的角度講解了如何實現“開-閉”原則。
“可變性的封裝原則”意味著兩點：
1．一種可變性不應當散落在代碼的很多角落里，而應當被封裝到一個對象里面。繼承應當被看做是封裝變化的方法，而不應當被認為是從一般的對象生成特殊的對象方法。
2．一種可變性不應當與另一種可變性混合在一起。所有的類圖的繼承結構一般不會超過兩層，不然就意味著將兩種不同的可變性混合在一起。
“開-閉”原則與其他原則的關系：
里氏代換原則是，任何基類可以出現的地方，子類一定可以出現。
里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化，而基類與子類的繼承關系就是抽象化的具體體現，所以里氏代換原則是對實現抽象化的具體步驟的規范。違反里氏代換原則的，也違背“開-閉”原則，反之不一定成立。
依賴倒轉原則是，要依賴于抽象，不要依賴于實現。
“開-閉”原則是目標，依賴倒轉原則是手段。
合成/聚合復用原則是，要盡量使用合成/聚合，而不是繼承關系達到復用的目的。
合成/聚合復用原則與里氏代換原則相輔相成，兩者都是實現“開-閉”原則的具體步驟的規范。
迪米特法則是，一個軟件實體應當與盡可能少的其他實體發生相互作用。
一個遵守迪米特原則設計出來的系統在功能需要擴展時，會相對更容易地做到對修改的關閉。
接口隔離原則是，應當為客戶端提供盡可能小的單獨的接口，而不是提供大的總接口。
接口隔離原則與廣義的迪米特法則都是對一個軟件實體與其他的軟件實體的通信的限制。遵循接口隔離原則，會使一個軟件系統在功能擴展的過程當中，不會將修改的壓力傳遞到其他的對象。
一個重構方法的討論
“將條件轉移語句改寫成為多態性”是一條廣為流傳的代碼重構做法。
這一做法本身并不能保證“開-閉”原則，應當以“開-閉”原則判斷是否需要改寫成多態。條件轉移并不是錯誤，如果需要，完全可以選擇使用條件轉移。
如果一個條件轉移語句確實封裝了某種商務邏輯的可變性，那么將此種可變性封裝起來就符合“開-閉”原則設計思想了。如果一個條件轉移語句沒有涉及重要的商務邏輯，或者不會隨著時間的變化而變化，也不意味著任何的可擴展性，那么它就沒有涉及任何有意義的可變性。這時候將這個條件轉移語句改寫成多態性就是一種沒有意義的浪費。
抽象類應當擁有盡可能多的共同代碼
在一個繼承的等級結構中，共同的代碼應當盡量向等級結構的上方移動。把重復的代碼從子類里面移動到超類里面，可以提高代碼的復用率。在代碼發生改變時，設計師之需要修改一個地方。
抽象類應當擁有盡可能少的數據
與代碼的移動方向相反，數據的移動方向是從抽象類到具體類，向等級結構的下方移動。一個對象的數據不論是否使用都會占用資源，所以應當放到等級結構的低端。
什么時候才應當使用繼承復用
1．子類是超類的一個特殊種類，而不是超類的一個角色，Is-A才符合繼承關系。
2．永遠不會出現需要將子類換成另一個類的子類的情況。
3．子類具有擴展超類的責任，而不是具有置換掉（Override）和注銷掉（Nullify）超類的責任。
4．只有在分類學角度上有意義時，才可以使用繼承，不要從工具類繼承。