「開-閉」原則 （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．只有在分類學角度上有意義時，才可以使用繼承，不要從工具類繼承。
設計原則與軟體設計
眾所周知，設計原則是設計模式的基石。當遵循設計原則的時候，寫出的 就會變得非常靈活，並且可以應對變化，也更加容易維護。當然，也不是那麼絕對。下面首先會簡要介紹一些基本的設計原則，然後再介紹robert c.martin的s.o.l.i.d原則。1 設計原則簡述 kiss原則 keep it stup...
軟體設計模式與原則
軟體設計模式 designpattern 是一套被反覆使用的 設計經驗總結。使用設計模式是為了可重用 讓 更容易被他人理解 保證 可靠性。好的設計，成就好的作品。但在軟體設計的過程中，若有一些設計原則 design principle 的約束，那我們的軟體會重構得更好。設計模式和設計原則博大精深，需...
軟體設計原則
開閉原則 ocp 軟體設計的最大原則 這個原則說的是 對擴充套件開放，對修改關閉。其實意思是說，給系統新增新的功能，但不修改原有 如果能做到呢，關鍵在於抽象化，也就是封裝變化，抽象層不變，讓具體實現依賴抽象隨需求變化。使得系統具有很強的擴充套件性和可維護性。黎克特制代換原則 任何基類可以出現的地方，...