小菜說的好：很多設計模式其實就是原則的應用而已。
總結設計模式的原則可以得到六個即五個原則乙個法則。
單一職責原則
就乙個類而言，應該僅有乙個引起它變化的原因。
簡單理解：乙個類功能要單一。如果乙個類承擔的職責過多就等於把這些職責耦合在一起，乙個職責的變化可能會削弱或者一直這個類完成其他職責的能力。發生變化時會對設計產生意想不到的破壞。
例子：烤肉者就管烤肉,他也不管收錢,也不管記錄.這樣把"地攤"上的烤肉者分成服務員和烤肉的人。讓職責單一。
開放封閉原則
軟體實體（類、模組、函式等）應該可以擴充套件，但是不可修改。
即對擴充套件是開放的，對修改時封閉的。模組不可能完全封閉，設計時應該對封閉哪些變化做出選擇，猜測最有可能發生變化的種類，然後構造抽象來隔離它。查明可能發生的變化所等待的時間越長，要建立抽象就越困難，所以應該盡早發現。遵循開閉原則的好處：可維護、可復用、可擴充套件、靈活性好，是物件導向設計的核心。但是對應用程式的每個部分都可以的進行抽象同樣不是乙個好主意。
例子：簡單工廠模式
對於簡單工廠模式.我們有能力預知到未來可能新增計算,所以,我們將運算類抽象出來.為了以後方便擴充套件.這裡的運算類是不可以修改的.但是對於他的子類.我們是可以擴充套件的。
依賴倒轉原則
a、高層模組不應該依賴低層模組，二者都應該依賴抽象。
b、抽象不應該依賴細節，細節應該依賴抽象。
依賴倒轉原則是物件導向的標誌，用那種語言編寫程式不重要，如果編寫時考慮的是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關係都是終止於抽象類或者是介面，那就是物件導向的設計，否則就是面向過程的設計。
例子：觀察者模式
這裡的通知者,就不應該是具體.因為我們應當考慮到如果前台那裡換了人怎麼辦?這個通知還可以是其他人通知.比如老闆要通知去做某件事怎麼辦?為了讓大家都能用這個通知.所以要設定成抽象的.這裡的前台,老闆都要依賴這個通知.也就是說.細節要依賴抽象。
黎克特制代換原則
子型別必須能夠替換掉它們的父類。
乙個軟體實體如果使用的是乙個父類的話，那麼一定適用於其子類，而且它察覺不出父類物件和子類物件的區別。即在軟體裡，父類可以替換成子類，程式的行為沒有變化。
例子：迪公尺特法則
如果兩個類不必直接通訊，那麼兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法的話，可以通過第三者**這個呼叫。
在類的結構設計上，每乙個類都應當盡量降低成員的訪問許可權。迪公尺特法則強調了類之間的松耦合。類之間的耦合越弱，越有利於復用，乙個處於弱耦合的類被修改，不會對有關係的類造成波及。
合成聚合復用原則
盡量使用合成聚合，盡量不要使用類繼承。
聚合表示一種耦合擁有關係，體現的是
a物件可以包含
b物件，但是
b物件不是
a物件的一部分；合成是一種強的擁有關係，體現了嚴格的部分和整體的關係，部分和整體的生命週期一樣。優先使用物件的合成聚合有助於保持每個類被封裝，並被集中在單個任務上。這樣類和類繼承層次會保持較小的規模，並且不會增長為不可控的龐然大物。
設計模式之設計原則
設計模式 design pattern 是物件導向技術的最新進展之一，由於物件導向設計的靈活性，增加了其設計的複雜性，設計模式的出現就是為了提高復用的設計方案，讓 更容易被他人理解 保證 可靠性。設計模式於己於他人於系統都是多贏的，設計模式使 編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊...
設計模式之設計原則
類應該對擴充套件開放，對修改關閉。使用介面及抽象類實現 目的 減少影響原有的方法 高層模組不應該依賴低層模組，兩者都應該依賴其抽象。依賴抽象類，不要依賴具體類 針對介面程式設計，不要針對實現程式設計 目的 解耦合 就乙個類而言，應該僅有乙個引起它變化的原因 當乙個類耦合了多個職責，當其中乙個職責發生...
設計模式之設計原則
1 單一職責原則 srp 1 就乙個類而言，應該僅有乙個引起它變化的原因。2 軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。2 開放 封閉原則 1 軟體實體 類 模組 函式等等 對於擴充套件是開放的，對於更改是封閉的。2 在我們最初編寫 時，假設變化不會發生，當變化發生時，我們就建立...