java的設計模式大體上分為三大類：

建立型模式（5種）：工廠方法模式，抽象工廠模式，單例模式，建造者模式，原型模式。

結構型模式（7種）：介面卡模式，裝飾器模式，代理模式，外觀模式，橋接模式，組合模式，享元模式。

行為型模式（11種）：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。

設計模式遵循的原則有6個：

1、開閉原則（Open Close Principle）

對擴充套件開放，對修改關閉。

2、里氏代換原則（Liskov Substitution Principle）

只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新的行為。

3、依賴倒轉原則（Dependence Inversion Principle）

這個是開閉原則的基礎，對介面程式設計，依賴於抽象而不依賴於具體。

4、介面隔離原則（Interface Segregation Principle）

使用多個隔離的藉口來降低耦合度。

5、迪米特法則（最少知道原則）（Demeter Principle）

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

6、合成複用原則（Composite Reuse Principle）

原則是儘量使用合成/聚合的方式，而不是使用繼承。繼承實際上破壞了類的封裝性，超類的方法可能會被子類修改。

1. 工廠模式（Factory Method）

工廠模式（Factory Pattern）是 Java 中最常用的設計模式之一。這種型別的設計模式屬於建立型模式，它提供了一種建立物件的最佳方式。

在工廠模式中，我們在建立物件時不會對客戶端暴露建立邏輯，並且是通過使用一個共同的介面來指向新建立的物件。

介紹

意圖：定義一個建立物件的介面，讓其子類自己決定例項化哪一個工廠類，工廠模式使其建立過程延遲到子類進行。

主要解決：主要解決介面選擇的問題。

何時使用：我們明確地計劃不同條件下建立不同例項時。

如何解決：讓其子類實現工廠介面，返回的也是一個抽象的產品。

關鍵程式碼：建立過程在其子類執行。

應用例項：1、您需要一輛汽車，可以直接從工廠裡面提貨，而不用去管這輛汽車是怎麼做出來的，以及這個汽車裡面的具體實現。 2、Hibernate 換資料庫只需換方言和驅動就可以。

優點：1、一個呼叫者想建立一個物件，只要知道其名稱就可以了。 2、擴充套件性高，如果想增加一個產品，只要擴充套件一個工廠類就可以。 3、遮蔽產品的具體實現，呼叫者只關心產品的介面。

缺點：每次增加一個產品時，都需要增加一個具體類和物件實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。

使用場景：1、日誌記錄器：記錄可能記錄到本地硬碟、系統事件、遠端伺服器等，使用者可以選擇記錄日誌到什麼地方。 2、資料庫訪問，當用戶不知道最後系統採用哪一類資料庫，以及資料庫可能有變化時。 3、設計一個連線伺服器的框架，需要三個協議，"POP3"、"IMAP"、"HTTP"，可以把這三個作為產品類，共同實現一個介面。

注意事項：作為一種建立類模式，在任何需要生成複雜物件的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜物件適合使用工廠模式，而簡單物件，特別是只需要通過 new 就可以完成建立的物件，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。

常用的工廠模式是靜態工廠，利用static方法，作為一種類似於常見的工具類Utils等輔助效果，一般情況下工廠類不需要例項化。

interface food{}
class A implements food{}
class B implements food{}
class C implements food{}
public class StaticFactory {
    private StaticFactory(){}
    public static food getA(){  return new A(); }
    public static food getB(){  return new B(); }
    public static food getC(){  return new C(); }
}
class Client{
    //客戶端程式碼只需要將相應的引數傳入即可得到物件
    //使用者不需要了解工廠類內部的邏輯。
    public void get(String name){
        food x = null ;
        if ( name.equals("A")) {
            x = StaticFactory.getA();
        }else if ( name.equals("B")){
            x = StaticFactory.getB();
        }else {
            x = StaticFactory.getC();
        }
    }
}

2. 抽象工廠模式（Abstract Factory）

一個基礎介面定義了功能，每個實現介面的子類就是產品，然後定義一個工廠介面，實現了工廠介面的就是工廠，這時候，介面程式設計的優點就出現了，我們可以新增產品類（只需要實現產品介面），只需要同時新增一個工廠類，客戶端就可以輕鬆呼叫新產品的程式碼。

抽象工廠的靈活性就體現在這裡，無需改動原有的程式碼，畢竟對於客戶端來說，靜態工廠模式在不改動StaticFactory類的程式碼時無法新增產品，如果採用了抽象工廠模式，就可以輕鬆的新增拓展類。

例項程式碼：

interface food{}
class A implements food{}
class B implements food{}
interface produce{ food get();}
class FactoryForA implements produce{
    @Override
    public food get() {
        return new A();
    }
}
class FactoryForB implements produce{
    @Override
    public food get() {
        return new B();
    }
}
public class AbstractFactory {
    public void ClientCode(String name){
        food x= new FactoryForA().get();
        x = new FactoryForB().get();
    }
}

3. 單例模式（Singleton）

單例模式（Singleton Pattern）是 Java 中最簡單的設計模式之一。這種型別的設計模式屬於建立型模式，它提供了一種建立物件的最佳方式。

這種模式涉及到一個單一的類，該類負責建立自己的物件，同時確保只有單個物件被建立。這個類提供了一種訪問其唯一的物件的方式，可以直接訪問，不需要例項化該類的物件。

注意：

• 1、單例類只能有一個例項。
• 2、單例類必須自己建立自己的唯一例項。
• 3、單例類必須給所有其他物件提供這一例項。

介紹

意圖：保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。

主要解決：一個全域性使用的類頻繁地建立與銷燬。

何時使用：當您想控制例項數目，節省系統資源的時候。

如何解決：判斷系統是否已經有這個單例，如果有則返回，如果沒有則建立。

關鍵程式碼：建構函式是私有的。

應用例項：

• 1、一個班級只有一個班主任。
• 2、Windows 是多程序多執行緒的，在操作一個檔案的時候，就不可避免地出現多個程序或執行緒同時操作一個檔案的現象，所以所有檔案的處理必須通過唯一的例項來進行。
• 3、一些裝置管理器常常設計為單例模式，比如一個電腦有兩臺印表機，在輸出的時候就要處理不能兩臺印表機列印同一個檔案。

優點：

• 1、在記憶體裡只有一個例項，減少了記憶體的開銷，尤其是頻繁的建立和銷燬例項（比如管理學院首頁頁面快取）。
• 2、避免對資源的多重佔用（比如寫檔案操作）。

缺點：沒有介面，不能繼承，與單一職責原則衝突，一個類應該只關心內部邏輯，而不關心外面怎麼樣來例項化。

使用場景：

• 1、要求生產唯一序列號。
• 2、WEB 中的計數器，不用每次重新整理都在資料庫里加一次，用單例先快取起來。
• 3、建立的一個物件需要消耗的資源過多，比如 I/O 與資料庫的連線等。

注意事項：getInstance() 方法中需要使用同步鎖 synchronized (Singleton.class) 防止多執行緒同時進入造成 instance 被多次例項化。

在內部建立一個例項，構造器全部設定為private，所有方法均在該例項上改動，在建立上要注意類的例項化只能執行一次，可以採用許多種方法來實現，如Synchronized關鍵字，或者利用內部類等機制來實現。

單例模式的幾種實現方式

1、懶漢式，執行緒不安全

是否 Lazy 初始化：是

是否多執行緒安全：否

實現難度：易

描述：這種方式是最基本的實現方式，這種實現最大的問題就是不支援多執行緒。因為沒有加鎖 synchronized，所以嚴格意義上它並不算單例模式。
這種方式 lazy loading 很明顯，不要求執行緒安全，在多執行緒不能正常工作。

接下來介紹的幾種實現方式都支援多執行緒，但是在效能上有所差異。

2、懶漢式，執行緒安全

是否 Lazy 初始化：是

是否多執行緒安全：是

實現難度：易

描述：這種方式具備很好的 lazy loading，能夠在多執行緒中很好的工作，但是，效率很低，99% 情況下不需要同步。
優點：第一次呼叫才初始化，避免記憶體浪費。
缺點：必須加鎖 synchronized 才能保證單例，但加鎖會影響效率。
getInstance() 的效能對應用程式不是很關鍵（該方法使用不太頻繁）。

3、餓漢式

是否 Lazy 初始化：否

是否多執行緒安全：是

實現難度：易

描述：這種方式比較常用，但容易產生垃圾物件。
優點：沒有加鎖，執行效率會提高。
缺點：類載入時就初始化，浪費記憶體。
它基於 classloader 機制避免了多執行緒的同步問題，不過，instance 在類裝載時就例項化，雖然導致類裝載的原因有很多種，在單例模式中大多數都是呼叫 getInstance 方法， 但是也不能確定有其他的方式（或者其他的靜態方法）導致類裝載，這時候初始化 instance 顯然沒有達到 lazy loading 的效果。

4、雙檢鎖/雙重校驗鎖（DCL，即 double-checked locking）

JDK 版本：JDK1.5 起

是否 Lazy 初始化：是

是否多執行緒安全：是

實現難度：較複雜

描述：這種方式採用雙鎖機制，安全且在多執行緒情況下能保持高效能。
getInstance() 的效能對應用程式很關鍵。

5、登記式/靜態內部類

是否 Lazy 初始化：是

是否多執行緒安全：是

實現難度：一般

描述：這種方式能達到雙檢鎖方式一樣的功效，但實現更簡單。對靜態域使用延遲初始化，應使用這種方式而不是雙檢鎖方式。這種方式只適用於靜態域的情況，雙檢鎖方式可在例項域需要延遲初始化時使用。
這種方式同樣利用了 classloader 機制來保證初始化 instance 時只有一個執行緒，它跟第 3 種方式不同的是：第 3 種方式只要 Singleton 類被裝載了，那麼 instance 就會被例項化（沒有達到 lazy loading 效果），而這種方式是 Singleton 類被裝載了，instance 不一定被初始化。因為 SingletonHolder 類沒有被主動使用，只有通過顯式呼叫 getInstance 方法時，才會顯式裝載 SingletonHolder 類，從而例項化 instance。想象一下，如果例項化 instance 很消耗資源，所以想讓它延遲載入，另外一方面，又不希望在 Singleton 類載入時就例項化，因為不能確保 Singleton 類還可能在其他的地方被主動使用從而被載入，那麼這個時候例項化 instance 顯然是不合適的。這個時候，這種方式相比第 3 種方式就顯得很合理。

6、列舉

JDK 版本：JDK1.5 起

是否 Lazy 初始化：否

是否多執行緒安全：是

實現難度：易

描述：這種實現方式還沒有被廣泛採用，但這是實現單例模式的最佳方法。它更簡潔，自動支援序列化機制，絕對防止多次例項化。
這種方式是 Effective Java 作者 Josh Bloch 提倡的方式，它不僅能避免多執行緒同步問題，而且還自動支援序列化機制，防止反序列化重新建立新的物件，絕對防止多次例項化。不過，由於 JDK1.5 之後才加入 enum 特性，用這種方式寫不免讓人感覺生疏，在實際工作中，也很少用。
不能通過 reflection attack 來呼叫私有構造方法。

經驗之談：一般情況下，不建議使用第 1 種和第 2 種懶漢方式，建議使用第 3 種餓漢方式。只有在要明確實現 lazy loading 效果時，才會使用第 5 種登記方式。如果涉及到反序列化建立物件時，可以嘗試使用第 6 種列舉方式。如果有其他特殊的需求，可以考慮使用第 4 種雙檢鎖方式。