設計模式（design pattern）是物件導向技術的最新進展之一，由於物件導向設計的靈活性，增加了其設計的複雜性，設計模式的出現就是為了提高復用的設計方案，讓**更容易被他人理解、保證**可靠性。設計模式於己於他人於系統都是多贏的，設計模式使**編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。
要想用好設計模式，必須先明白設計模式的六大原則：單一職責原則、開放封閉原則、依賴倒轉原則、黎克特制代換原則、合成聚合復用原則、迪公尺特法則。
單一職責原則，就乙個類而言，應該僅有乙個引起它變化的原因。如果乙個類承擔的職責過多，就等於把這些職責耦合在一起，乙個職責的變化可能會消弱或者一直這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。而軟體設計真正要做的許多內容，就是發現職責，並把這些職責相互分離。
開放-封閉原則，是說軟體實體（類、模組、函式等等）應該可以擴充套件，但是不可以修改。即對於擴充套件是開放的，對於更改是封閉的。當使用者需求的變化，不鞥輕易更改源**，而是應該建立抽象類，去隔離以後發生的同類變化。這樣會使得變化中的系統有一定的穩定性和延續性。
例如當年玉皇大帝在不更改現有天庭秩序的情況下，成功擴充套件「弼馬溫」這個秩序（類）。
抽象不應該依賴細節，細節應該依賴於抽象。即我們要針對介面（抽象類）程式設計，不要針對與實現程式設計。
比如你開車進小區，小王是門衛，每次你到門口，喊一聲「小王，幫忙開下門」他就給你開了，但是對於剛搬進小區的小李，他可不認識小王，他怎麼通知小王開門呢？假如突然有一天，門衛換了，難道你就不進小區了？答案大家都知道，只要喊「門衛，幫忙開下門」，你和小李就都可以進去了。所以不管門衛和小區的業主怎麼換，只要「門衛」這個「介面」是不變，那麼業主就可以讓門衛給開門。
黎克特制代換原則，子型別必須能夠替換掉他們的父型別。在軟體裡面，把父類都替換成其子類，程式的行為不會發生變化。
簡單來說，子類=父類[+新功能]。父類的非私有成員都會被子類繼承，還可以根據自身情況對繼承來的方法diy。當用子類去例項化父類，呼叫父類的方法，具體實現則是剛才的子類的方法。（也就是說如果這個父類有多個子類的話，只要用不同的子類去例項化這個父類，那麼這個父類物件執行相同的方法，則會執行各自子類對應的同名方法，所以結果也會不同。而這就是「多型」！所以可以說多型是黎克特制代換原則的體現。）當然反過來是不成立的。例如矩形和正方形，我們可以說正方形是一種特殊的矩形，但不可以說矩形是一種特殊的正方形。
合成聚合復用原則：盡量使用合成\聚合，盡量不使用類繼承。合成聚合是」has a」的關係，而繼承是「is a」的關係。由於繼承是一中強耦合的結構，父類變，子類必變。所以不是「is a」關係，我們一般不要用繼承。優先使用合成聚合復用原則，可以保持每個類的封裝，降低繼承的層次。
根據此原則轉變後為：
如果兩個類不必彼此直接通訊，那麼這兩個類就不應當發生直接的相互作用。如果其中乙個類需要呼叫另乙個類的某乙個方法時，可以通過第三者**這個呼叫。類之間的耦合越弱，就越有利於復用，乙個處在弱耦合的類被修改，不會對有關係的類造成波及。也就是說，乙個物件對其他物件盡可能少的了解（不要和陌生人說話）。
設計模式之設計原則
類應該對擴充套件開放，對修改關閉。使用介面及抽象類實現 目的 減少影響原有的方法 高層模組不應該依賴低層模組，兩者都應該依賴其抽象。依賴抽象類，不要依賴具體類 針對介面程式設計，不要針對實現程式設計 目的 解耦合 就乙個類而言，應該僅有乙個引起它變化的原因 當乙個類耦合了多個職責，當其中乙個職責發生...
設計模式之設計原則
1 單一職責原則 srp 1 就乙個類而言，應該僅有乙個引起它變化的原因。2 軟體設計真正要做的許多內容，就是發現職責並把那些職責相互分離。2 開放 封閉原則 1 軟體實體 類 模組 函式等等 對於擴充套件是開放的，對於更改是封閉的。2 在我們最初編寫 時，假設變化不會發生，當變化發生時，我們就建立...
設計模式之原則
前言 設計模式的原則是設計模式的需要遵守的規範，設計模式滿足的規則越多那麼這個模式也就越精闢，我們根據設計自己的 結構的時候要把遵循這些原則作為前提，否則維護時的代價就是巨大的。就乙個類而言，應該僅有乙個引起它變化的原因。這是什麼意思呢，就想我們如果在乙個類裡面包含了很多功能，比如訪問資料庫 運算演...