摘要：這個模式感覺一一般和工廠模式一起使用的比較多比較方便結構型模式這些設計模式關注類和對象的組合。設計模式這些設計模式特別關注表示層。

學習設計模式之前最好先了解一下設計模式的設計原則：

1. 開閉原則（open close principle）

開放即指對擴展開放，對修改關閉 簡而言之，就是擴展功能的時候應該盡量的不修改原有的代碼。

2. 里氏代換原則（liskov substitution principle）

可以簡單理解為派生類與基類的替換關系，一旦程序中出現基類，那么這個基類若是唄派生類替換了，也應該是合適的，并且對程序功能不受影響，該原則實際上是開閉原則的補充。 基類能真正復用，派生類也能夠在基類的基礎上增加新的行為。實現開閉原則的關鍵步驟就是抽象化，而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。

3. 依賴倒轉原則（dependence inverse principle）

這個原則是開閉原則的基礎，具體內容：針對接口編程，依賴于抽象而不依賴于具體。

4. 接口隔離原則（Interface Segregation Principle）

使用多個隔離的接口，比使用單個接口要好，該模式出發點在與大一點的軟件設計架構，便于維護升級，降低耦合度。

5.迪米特法則，又稱最少知道原則（Demeter Principle）

一個實體應當盡量少地與其他實體之間發生相互作用，使得系統功能模塊相對獨立。

6. 合成復用原則（Composite Reuse Principle）
盡量使用合成/聚合的方式，而不是使用繼承。

創建型模式（creational pattern）

隱藏創建對象的創建邏輯，提供創建對象的接口，而非使用new關鍵字進行創建。

工廠模式（factory pattern）

隱藏創建的對象的邏輯，通過共同對的接口創建對象。

實現demo結構如下圖,實現demo代碼點這里這是我學習的時候寫的demo

抽象工廠模式（abstract factory pattern）

這個模式是工廠的共工廠 叫超級工廠模式還比較貼切，在抽象工廠模式中，接口是負責創建一個相關對象的工廠，不需要顯式指定它們的類。每個生成的工廠都能按照工廠模式提供對象。

單例模式（singleton pattern）

一個類負責創建自己的對象，同時確保只有單個對象被創建。這個類提供了一種訪問其唯一的對象的方式，可以直接訪問，不需要實例化該類的對象

不支持線程的懶漢單例模式

public class Singleton_unsupport_multithread {

    private Singleton_unsupport_multithread() {
        // TODO Auto-generated constructor stub
    **}

    private static Singleton_unsupport_multithread instance;

    public static Singleton_unsupport_multithread getSingleton() {

        if (instance == null) {
            instance = new Singleton_unsupport_multithread();
        }

        return instance;
    }

    public void println() {
        System.out.println("In unsupport_multithread");
    }

}

支持多線程的懶漢單例模式

public class Singleton_support_multithread {

    private Singleton_support_multithread() {
        // TODO Auto-generated constructor stub
    }

    private static volatile Singleton_support_multithread instance;

    /**
     * 第一個判斷可以減少鎖住對象的情況 如果不為空直接返回 效率更高 
     * 第二個判斷就是懶加載的判斷
     * 
     * @return
     */
    public static Singleton_support_multithread getInstance() {
        if (instance == null) {
            synchronized (Singleton_support_multithread.class) {
                if (instance == null)
                    instance = new Singleton_support_multithread();
            }
        }

        return instance;
    }

}

餓漢單例模式

/**
 * 
 * @author Vincent
 * 線程安全 但是容易產生垃圾對象，沒有加鎖執行效率會比較高 
 * 但不是懶加載 類一加載的時候就進行初始化 浪費內存
 *
 */
public class Singleton_hungry_man {

    private Singleton_hungry_man() {
        // TODO Auto-generated constructor stub
    }

    private static Singleton_hungry_man instance = new Singleton_hungry_man();

    public static Singleton_hungry_man getInstance() {

        return instance;

    }

}

登記注冊單例模式

/**
 * 
 * @author Vincent
 * 登記注冊式 單例
 * 這里其實與前面的餓漢單例模式有點類似 但是由于利用了ClassLoaderDe特性 
 * 使在不調用的getInstance的時候不會初始化instance 實現了懶加載
 *
 */

public class Singleton_register {

    private static class SingletonHolder {
        private static Singleton_register instance = new Singleton_register();
    }

    private Singleton_register() {
        // TODO Auto-generated constructor stub
    }

    public static final Singleton_register getInstance() {
        return SingletonHolder.instance;
    }

}

枚舉單例模式

/**
 * 
 * @author Vincent
 * 講道理哦 這個方式最方便的單例模式 
 * 利用枚舉 自帶支持 序列化機制  防止反序列化多次創建對象 可以適應多線程 然而卻不怎么受待見 大多數人不用這個方式 可能和習慣有關系吧 = =   
 *
 */
public enum Singleton_enum {
        
    Instance;
    
}

建造者模式（builder pattern）

使用多個簡單的對象一步一步構建成一個復雜的對象。這種類型的設計模式屬于創建型模式，它提供了一種創建對象的最佳方式。值得一說的是感覺是這個設計模式 感覺更加注重內部對象的細節，內部零件裝配的順序。

原型模式（prototype pattern）

用于創建重復的對象，同時又能保證性能
這種模式是實現了一個原型接口，該接口用于創建當前對象的克隆。當直接創建對象的代價比較大時，則采用這種模式。
這個模式感覺一一般和工廠模式一起使用的比較多 比較方便

結構型模式（ctructural pattern）

這些設計模式關注類和對象的組合。繼承的概念被用來組合接口和定義組合對象獲得新功能的方式。

適配器模式（adapter pattern）

將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。

橋接模式（bridge pattern）

是用于把抽象化與實現化解耦，使得二者可以獨立變化，目的就是為了抽象與實現分離，都可以有獨立的變化，用抽象類依賴實現類來實現。

這里簡單說一下橋接模式與適配器模式的區別：從名字來理解比較容易理解，適配器嘛 那就是已經有了一些功能類，但是需要一個新的功能，這個時候沒必要寫重復的或者說現在有可重用的功能，就需要適配器了，打個比方，你現在有一個type-c接口的手機，還有一個圓孔耳機，手機是可以沒必要再“鉆”一個圓孔耳機孔，而耳機也不能錘扁為type-c，這個時候type-c轉接頭就來了，這就是一個適配器；但是橋接模式中，有一個根本的區別就是橋接模式一開始設計就是這樣的架構，是為了可擴展，而不是設配器模式是為了解決問題而誕生的，這是一種設計最初就存在的模式，橋接模式一般是一個抽象實體類，然后內部擁有功能接口的引用，這種結構很方便功能實現類的擴展，還有實體類的擴展。

過濾器模式（filter pattern）/標準模式（criteria pattern）

這個模式允許開發人員使用不同的標準過濾一組對象，通過該邏輯運算易解耦合的方式把他們連接起來，通過結合多個標準來獲得一個標準。

組合模式（composite pattern）

把一組相似的對象當作一個單一的對象。組合模式依據樹形結構來組合對象，用來表示部分以及整體層次，創建了對象組的樹形結構,創建了一個包含自己對象組的類，該類提供修改對象組的方式。

裝飾器模式（decorator pattern）

允許向一個現有的對象添加新的功能，同時又不改變其結構。這種類型的設計模式屬于結構型模式，它是作為現有的類的一個包裝。
這種模式創建了一個裝飾類，用來包裝原有的類，并在保持類方法簽名完整性的前提下，提供了額外的功能。

外觀模式（facade pattern）

該模式會隱藏系統復雜性，向現有的系統添加了一個接口。比如 電腦來講，開啟電腦的是會同時開啟CPU，硬盤，內存，但是我們只管開啟電腦而不需要知道其中內部的實現。

享元模式（flyweght pattern）

為了減少創建對象的數量來減少內存的占用提高性能，是對現有的對象嘗試重用，如果沒找到匹配的對象，則創建新的對象。比如：在String類中，會把創建多的字符串放在字符串緩存池里邊。
注意：

1.要區別出對象的內部狀態與外部狀態，否則容易有引起一些線程問題
1.一般與工廠模式混合使用，便于對象的管理

代理模式（proxy pattern）

在代理模式中，我們創建具有現有對象的對象，以便向外界提供功能接口，為其他對象提供一個代理以控制對這個對象的訪問。主要是為了隱藏被代理類的內部實現。

行為型模式（behavioral pattern）

這些設計模式特別關注對象之間的通信

責任鏈模式（chain of responsibility pattern）

請求創建了一個接收者對象的鏈。這種模式給予請求的類型，對請求的發送者和接收者進行解耦在這種模式中，通常每個接收者都包含對另一個接收者的引用。如果一個對象不能處理該請求，那么它會把相同的請求傳給下一個接收者，依此類推。

命令行模式（command pattern）

一種數據驅動的設計模式，請求以命令的形式包裹在對象中，并傳給調用對象。調用對象尋找可以處理該命令的合適的對象，并把該命令傳給相應的對象，該對象執行命令

解釋模式（interpreter pattern）

提供了余元的語法或表達式的方式，屬于行為模式,這種模式實現了一個表達式接口，該接口解釋一個特定的上下文，一般用于SQL解析，符號處理解析引擎之類。這個模式一般比較少見。

迭代器模式（iterator pattern）

這個模式用于順序訪問集合對象的元素，而不需要知道底層對象的表示。

中介者模式（mediator pattern）

用于降低多個對象和類之間的通信復雜性。提供了中介類，這個中介類負責處理不同類之間的通信，使系統降耦合。
適用場景：系統對象之間存在比較復雜的引用關系，導致他們之間的依賴關系結構混亂難以復用；或者想通過一個中間類封裝多個類中的行為，而又不想生成太多的子類。

觀察者模式（observer pattern）

當對象存在一對多的關系時候，比如：一個對象被修改的時候，就會通知他它的依賴對象。

實現方式：在抽象類里使用觀察者列表。

注意事項: 使用的時候不要循環引用

狀態模式(state pattern )

類的行為是根據其狀態而定的，在狀態模式中,通常創建的表示狀態的對象和一個行為隨著狀態對象改變而改變的context對象。
允許對象在內部狀態發生改變的時候改變它的行為。

空對象模式(null object pattern)

一個可能空對象取代null對象的例的檢查，null對象不是檢查空值,而是反應一個不做任何動作的關系，這樣的null對象也可以在數據不可用的時候提供默認的行為。
空對象模式中，通常創建一個指定各種要執行的操作的抽象類和擴展該類的實體類，然后創建未對該類做任何實現的空對象類，該類可以無縫的使用在需要檢查空值的地方。

J2EE設計模式（behavioral pattern）

這些設計模式特別關注表示層。這些模式是由 Sun Java Center 鑒定的。