設計模式，是在特定條件下，解決某一特定問題的方法或方式，是經過長期的經驗積累而來。

    給一個正式的定義：設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。

    使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。

    毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。

    GoF的“設計模式”是第一次將設計模式提升到理論高度，並將之規範化，書裡提出了23種基本設計模式，自此，在可複用面向物件軟體的發展過程中，新的大量的設計模式不斷出現。

    長話短說，我們先來看看軟體設計方面所追尋的幾個基本原則：

    1， “開-閉”原則：人們總是希望自己設計的東西具有可擴充套件性，在軟體領域裡就是希望不修改原始碼的情況下改變模組的行為。簡言之：對擴充套件開放，對修改關閉。“開-閉”原則是最根本的原則，其他原則是實現它的不同路徑，是從其他角度對“開-閉”原則的描述。

    2， 里氏代換原則：如果有一個基類適用於某一個介面，則其子類必然也適用。這是多型的基礎，也是繼承複用的基石，子類代替基類對系統沒任何影響時，基類才能真正被複用，而子類才能在基類的基礎上增加新的行為。

    3， 依賴倒轉原則：要依賴抽象介面程式設計，不要依賴具體實現程式設計。其實就是應當使用抽象介面來進行變數的型別宣告、參量的型別宣告、方法的返回型別宣告，以及資料型別的轉換等，而不應當使用具體實現。

    4， 介面隔離原則：使用多個專門的介面，比使用單一的總介面要好。從客戶類的角度來講：一個類對另一個類的依賴性應當是建立在最小的介面上的。

    5， 單一職責原則：只能讓一個類有且僅有一個職責，這也是單一職責原則的命名含義。換句話說，如果一個類需要改變，改變它的理由永遠只有一個。如果存在多個改變它的理由，就需要重新設計該類。也就是永遠不要讓一個類存在多個改變的理由。

    6， 合成/聚合複用原則：儘量使用合成/聚合，不要使用繼承。

    7， 迪米特法則：一個物件應當對其他物件有儘可能少的瞭解。通俗點就是不要跟陌生人說話。

    其實上面的那些原則主要是為了達到以下目的：

    1.少寫重複程式碼

    2.儘量不修改已經完成的程式碼

    3.如果要增加功能，最好是通過新增新的類，而不是修改現有程式碼。

    4.一定要修改的話，也要容易修改，並且不會或儘量少影響到其他。

    5....

    設計模式就是教我們如何在前輩們的經驗上，寫出可以滿足上面條件的程式碼。

    現在都是面向物件了，所以主要考慮的都是基於物件的重用。

    使用一個物件分為4步：

    1.定義這一類物件的通用模版----類（Class）

    2.建立/取得一個物件

    3.操作這個物件的方法以改變物件狀態

    4.銷燬這個物件。

    定義物件的模版時，就要考慮各類物件之間的複雜關係和結構，來描述一些複雜的事務，當然就是結構模式了。

    如何建立一個物件自然就是建立模式。

    操作物件呢就是行為模式了。

    銷燬一個物件比較容易，但是會經常忘，小心點就是了，其模式大概不多。很多語言已經內建了垃圾收集器，自動幫我們照料這些瑣事。

    建立模式比起其他兩個稍微簡單一點，我們下一節就從建立模式說起。

附錄：

設計包的原則：

    1. 釋出/重用等價原則（REP）我們建立包的目的是為了給別人重用，所以重用的粒度就是釋出的粒度。
    2. 公共閉合原則（CCP） 因為相同原因而被修改的類應該放入一個包中，對應於“單一責任原則”。
    3. 公共重用原則（CRP）應該儘可能地將只被一個客戶使用的包與被多個不同客戶使用到的包分開。對應於“介面隔離原則”
    4. 非迴圈依賴原則（ADP）不要在包依賴圖中出現迴圈依賴。如a依賴於b， b依賴於c，同時c又依賴於a。
    5. 穩定依賴原則（SDP）要依賴於穩定的包，而不要依賴於經常變化的包。對應於“依賴倒置原則”。
    6. 穩定抽象原則（SAP）穩定的包應當是抽象的。對應於“依賴倒置原則”。