設計模式中的幾大原則總結

單一職責原則：就一個類而言，應該僅有一個引起它變化的原因。
如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。
軟體設計真正要做的許多內容，就是發現職責並把這些職責相互分離。其實要去判斷是否應該分離出類來，也不難，那就是如果你能想到多於一個的動機去改變一個類，那個這個類就具有多於一個的職責。
開放-封閉原則：是說軟體實體（類，模組，函式等等）應該可以擴充套件，但是不可修改。
無論模組是多麼的‘封閉’，都會存在一些無法對指的封閉變化。既然不可能完全封閉，設計人員必須對他設計的模組應該對應那種變化封閉做出選擇，他必須先猜測出最可能發生變化的種類，然後構建抽象來隔離那些變化。
在我們最初編寫程式碼時，假設程式碼不會發生變化。當變化發生時，我們就建立抽象類隔離以後發生的同類變化。
開發-封閉原則是物件導向設計的核心所。遵循這個原則可以帶來物件導向技術所聲稱的巨大好處，也就是可維護，可擴充套件，可複用，靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程式中的每個部分都刻意地進行抽象同樣不是一個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
依賴倒轉原則：
A.高層模組不應該依賴底層模組。兩個都應該依賴抽象。
B.抽象不應該依賴細節。細節應該依賴抽象。
里氏代換原則：
子型別必須能夠替換掉它們的父型別。
迪米特法則：
如果兩個類不必彼此直接通訊，那麼這兩個類就不應該發生直接關係的相互作用。如果其中一個類需要呼叫另一個類的某一個方法的話，可以通過第三者轉發這個呼叫。
合成/聚合複用原則：
儘量使用合成/聚合，儘量不要使用類繼承。
優先使用物件的合成/聚合將有助你保持每個類的封裝，並被集中在單個任務中，這樣類和類繼承層次會保持較小的規模，並且不太可能增長為不可控制的龐然大物。
參考：《大話設計模式》

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29012686/viewspace-1122691/，如需轉載，請註明出處，否則將追究法律責任。