經常使用設計模式之單例模式和工廠模式

•  單例模式

java中單例模式是一種常見的設計模式，單例模式的寫法有好幾種，這裏主要介紹三種：懶漢式單例、餓漢式單例、登記式單例。

　　單例模式有如下特色：

　　1、單例類只能有一個實例。

　　2、單例類必須本身建立本身的惟一實例。

　　3、單例類必須給全部其餘對象提供這一實例。

　　單例模式確保某個類只有一個實例，並且自行實例化並向整個系統提供這個實例。在計算機系統中，線程池、緩存、日誌對象、對話框、打印機、顯卡的驅動程序對象常被設計成單例。這些應用都或多或少具備資源管理器的功能。每臺計算機能夠有若干個打印機，但只能有一個Printer Spooler，以免兩個打印做業同時輸出到打印機中。每臺計算機能夠有若干通訊端口，系統應當集中管理這些通訊端口，以免一個通訊端口同時被兩個請求同時調用。總之，選擇單例模式就是爲了不不一致狀態，避免政出多頭。

一 ： 懶漢式 單例
1. //懶漢式單例類.在第一次調用的時候實例化本身   
2. public class Singleton {  
3.     private Singleton() {}  
4.     private static Singleton single=null;  
5.     //靜態工廠方法   
6.     public static Singleton getInstance() {  
7.          if (single == null) {    
8.              single = new Singleton();  
9.          }    
10.         return single;  
11.     }  
12. }  
1、在getInstance方法上加同步
1. public static synchronized Singleton getInstance() {  
2.          if (single == null) {    
3.              single = new Singleton();  
4.          }    
5.         return single;  
6. }  
2、雙重檢查鎖定
1. public static Singleton getInstance() {  
2.         if (singleton == null) {    
3.             synchronized (Singleton.class) {    
4.                if (singleton == null) {    
5.                   singleton = new Singleton();   
6.                }    
7.             }    
8.         }    
9.         return singleton;   
10.     }  
 
3、靜態內部類
1. public class Singleton {    
2.     private static class LazyHolder {    
3.        private static final Singleton INSTANCE = new Singleton();    
4.     }    
5.     private Singleton (){}    
6.     public static final Singleton getInstance() {    
7.        return LazyHolder.INSTANCE;    
8.     }    
9. } 
 
二： 餓漢式單例
1. /餓漢式單例類.在類初始化時，已經自行實例化   
2. public class Singleton1 {  
3.     private Singleton1() {}  
4.     private static final Singleton1 single = new Singleton1();  
5.     //靜態工廠方法   
6.     public static Singleton1 getInstance() {  
7.         return single;  
8.     }  
9. }  
  

餓漢式和懶漢式區別

從名字上來講，餓漢和懶漢，

餓漢就是類一旦加載，就把單例初始化完成，保證getInstance的時候，單例是已經存在的了，而懶漢比較懶，只有當調用getInstance的時候，纔回去初始化這個單例。另外從如下兩點再區分如下這兩種方式：

一、線程安全：

餓漢式天生就是線程安全的，能夠直接用於多線程而不會出現問題，

懶漢式自己是非線程安全的，爲了實現線程安全有幾種寫法，分別是上面的一、二、3，這三種實如今資源加載和性能方面有些區別。

二、資源加載和性能：

餓漢式在類建立的同時就實例化一個靜態對象出來，無論以後會不會使用這個單例，都會佔據必定的內存，可是相應的，在第一次調用時速度也會更快，由於其資源已經初始化完成，

而懶漢式顧名思義，會延遲加載，在第一次使用該單例的時候纔會實例化對象出來，第一次調用時要作初始化，若是要作的工做比較多，性能上會有些延遲，以後就和餓漢式同樣了。

至於一、二、3這三種實現又有些區別，

第1種，在方法調用上加了同步，雖然線程安全了，可是每次都要同步，會影響性能，畢竟99%的狀況下是不須要同步的，

第2種，在getInstance中作了兩次null檢查，確保了只有第一次調用單例的時候纔會作同步，這樣也是線程安全的，同時避免了每次都同步的性能損耗

第3種，利用了classloader的機制來保證初始化instance時只有一個線程，因此也是線程安全的，同時沒有性能損耗，因此通常我傾向於使用這一種。

•  工廠模式

在面向對象編程中, 最一般的方法是一個new操做符產生一個對象實例,new操做符就是用來構造對象實例的。可是在一些狀況下, new操做符直接生成對象會帶來一些問題。舉例來講, 許多類型對象的創造須要一系列的步驟: 你可能須要計算或取得對象的初始設置; 選擇生成哪一個子對象實例; 或在生成你須要的對象以前必須先生成一些輔助功能的對象。 在這些狀況,新對象的創建就是一個 「過程」，不只是一個操做，像一部大機器中的一個齒輪傳動。

模式的問題：你如何能輕鬆方便地構造對象實例，而沒必要關心構造對象實例的細節和複雜過程呢？

解決方案：創建一個工廠來建立對象

實現：

1、引言

    1）尚未工廠時代：假如尚未工業革命，若是一個客戶要一款寶馬車,通常的作法是客戶去建立一款寶馬車，而後拿來用。

    2）簡單工廠模式：後來出現工業革命。用戶不用去建立寶馬車。由於客戶有一個工廠來幫他建立寶馬.想要什麼車，這個工廠就能夠建。好比想要320i系列車。工廠就建立這個系列的車。即工廠能夠建立產品。

    3）工廠方法模式時代：爲了知足客戶，寶馬車系列愈來愈多，如320i，523i,30li等系列一個工廠沒法建立全部的寶馬系列。因而由單獨分出來多個具體的工廠。每一個具體工廠建立一種系列。即具體工廠類只能建立一個具體產品。可是寶馬工廠仍是個抽象。你須要指定某個具體的工廠才能生產車出來。

   4）抽象工廠模式時代：隨着客戶的要求愈來愈高，寶馬車必須配置空調。因而這個工廠開始生產寶馬車和須要的空調。

   最終是客戶只要對寶馬的銷售員說：我要523i空調車，銷售員就直接給他523i空調車了。而不用本身去建立523i空調車寶馬車.

   這就是工廠模式。

2、分類 

        工廠模式主要是爲建立對象提供過渡接口，以便將建立對象的具體過程屏蔽隔離起來，達到提升靈活性的目的。 

工廠模式能夠分爲三類： 

1）簡單工廠模式（Simple Factory） 

2）工廠方法模式（Factory Method） 

3）抽象工廠模式（Abstract Factory） 

 這三種模式從上到下逐步抽象，而且更具通常性。 

        GOF在《設計模式》一書中將工廠模式分爲兩類：工廠方法模式（Factory Method）與抽象工廠模式（Abstract Factory）。

        將簡單工廠模式（Simple Factory）看爲工廠方法模式的一種特例，二者歸爲一類。 

3、區別 

工廠方法模式：

一個抽象產品類，能夠派生出多個具體產品類。   

一個抽象工廠類，能夠派生出多個具體工廠類。   

每一個具體工廠類只能建立一個具體產品類的實例。

抽象工廠模式：

多個抽象產品類，每一個抽象產品類能夠派生出多個具體產品類。   

一個抽象工廠類，能夠派生出多個具體工廠類。   

每一個具體工廠類能夠建立多個具體產品類的實例。   

區別：

工廠方法模式只有一個抽象產品類，而抽象工廠模式有多個。   

工廠方法模式的具體工廠類只能建立一個具體產品類的實例，而抽象工廠模式能夠建立多個。

二者皆可。 

 4、簡單工廠模式 

創建一個工廠（一個函數或一個類方法）來製造新的對象。

分佈說明引子：從無到有。客戶本身建立寶馬車，而後拿來用。

客戶須要知道怎麼去建立一款車,客戶和車就緊密耦合在一塊兒了.爲了下降耦合,就出現了工廠類,把建立寶馬的操做細節都放到了工廠裏面去,客戶直接使用工廠的建立工廠方法,傳入想要的寶馬車型號就好了,而沒必要去知道建立的細節.這就是工業革命了：簡單工廠模式

即咱們創建一個工廠類方法來製造新的對象。如圖：

  簡單工廠模式又稱靜態工廠方法模式。重命名上就能夠看出這個模式必定很簡單。它存在的目的很簡單：定義一個用於建立對象的接口。 

      先來看看它的組成： 

         1) 工廠類角色：這是本模式的核心，含有必定的商業邏輯和判斷邏輯，用來建立產品

         2) 抽象產品角色：它通常是具體產品繼承的父類或者實現的接口。         

         3) 具體產品角色：工廠類所建立的對象就是此角色的實例。在java中由一個具體類實現。 

        

        下面咱們從開閉原則（對擴展開放；對修改封閉）上來分析下簡單工廠模式。當客戶再也不知足現有的車型號的時候，想要一種速度快的新型車，只要這種車符合抽象產品制定的合同，那麼只要通知工廠類知道就能夠被客戶使用了。因此對產品部分來講，它是符合開閉原則的；可是工廠部分好像不太理想，由於每增長一種新型車，都要在工廠類中增長相應的建立業務邏輯（createBMW(int type)方法須要新增case），這顯然是違背開閉原則的。可想而知對於新產品的加入，工廠類是很被動的。對於這樣的工廠類，咱們稱它爲全能類或者上帝類。 

        咱們舉的例子是最簡單的狀況，而在實際應用中，極可能產品是一個多層次的樹狀結構。因爲簡單工廠模式中只有一個工廠類來對應這些產品，因此這可能會把咱們的上帝累壞了，也累壞了咱們這些程序員。

        因而工廠方法模式做爲救世主出現了。 工廠類定義成了接口,而每新增的車種類型,就增長該車種類型對應工廠類的實現,這樣工廠的設計就能夠擴展了,而沒必要去修改原來的代碼。

5、工廠方法模式 

        工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它能夠被子類繼承。這樣在簡單工廠模式裏集中在工廠方法上的壓力能夠由工廠方法模式裏不一樣的工廠子類來分擔。 

工廠方法模式組成： 

       1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 

       2)具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。 

       3)抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。 

       4)具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在java中由具體的類來實現。 

 

       工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的「上帝類」。正如上面所說，這樣便分擔了對象承受的壓力；並且這樣使得結構變得靈活 起來——當有新的產品產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就能夠被客戶使用，而沒必要去修改任何已有 的代碼。能夠看出工廠角色的結構也是符合開閉原則的！ 

  簡單工廠模式又稱靜態工廠方法模式。重命名上就能夠看出這個模式必定很簡單。它存在的目的很簡單：定義一個用於建立對象的接口。 

      先來看看它的組成： 

         1) 工廠類角色：這是本模式的核心，含有必定的商業邏輯和判斷邏輯，用來建立產品

         2) 抽象產品角色：它通常是具體產品繼承的父類或者實現的接口。         

         3) 具體產品角色：工廠類所建立的對象就是此角色的實例。在java中由一個具體類實現。 

        

        下面咱們從開閉原則（對擴展開放；對修改封閉）上來分析下簡單工廠模式。當客戶再也不知足現有的車型號的時候，想要一種速度快的新型車，只要這種車符合抽象產品制定的合同，那麼只要通知工廠類知道就能夠被客戶使用了。因此對產品部分來講，它是符合開閉原則的；可是工廠部分好像不太理想，由於每增長一種新型車，都要在工廠類中增長相應的建立業務邏輯（createBMW(int type)方法須要新增case），這顯然是違背開閉原則的。可想而知對於新產品的加入，工廠類是很被動的。對於這樣的工廠類，咱們稱它爲全能類或者上帝類。 

        咱們舉的例子是最簡單的狀況，而在實際應用中，極可能產品是一個多層次的樹狀結構。因爲簡單工廠模式中只有一個工廠類來對應這些產品，因此這可能會把咱們的上帝累壞了，也累壞了咱們這些程序員。

        因而工廠方法模式做爲救世主出現了。 工廠類定義成了接口,而每新增的車種類型,就增長該車種類型對應工廠類的實現,這樣工廠的設計就能夠擴展了,而沒必要去修改原來的代碼。

5、工廠方法模式 

        工廠方法模式去掉了簡單工廠模式中工廠方法的靜態屬性，使得它能夠被子類繼承。這樣在簡單工廠模式裏集中在工廠方法上的壓力能夠由工廠方法模式裏不一樣的工廠子類來分擔。 

工廠方法模式組成： 

       1)抽象工廠角色： 這是工廠方法模式的核心，它與應用程序無關。是具體工廠角色必須實現的接口或者必須繼承的父類。在java中它由抽象類或者接口來實現。 

       2)具體工廠角色：它含有和具體業務邏輯有關的代碼。由應用程序調用以建立對應的具體產品的對象。 

       3)抽象產品角色：它是具體產品繼承的父類或者是實現的接口。在java中通常有抽象類或者接口來實現。 

       4)具體產品角色：具體工廠角色所建立的對象就是此角色的實例。在java中由具體的類來實現。 

產品類：

1. abstract class BMW {  
2.     public BMW(){  
3.           
4.     }  
5. }  
6. public class BMW320 extends BMW {  
7.     public BMW320() {  
8.         System.out.println("製造-->BMW320");  
9.     }  
10. }  
11. public class BMW523 extends BMW{  
12.     public BMW523(){  
13.         System.out.println("製造-->BMW523");  
14.     }  
15. }  
   建立工廠類：
1. interface FactoryBMW {  
2.     BMW createBMW();  
3. }  
4.   
5. public class FactoryBMW320 implements FactoryBMW{  
6.   
7.     @Override  
8.     public BMW320 createBMW() {  
9.   
10.         return new BMW320();  
11.     }  
12.   
13. }  
14. public class FactoryBMW523 implements FactoryBMW {  
15.     @Override  
16.     public BMW523 createBMW() {  
17.   
18.         return new BMW523();  
19.     }  
20. }  
 客戶類：
1. public class Customer {  
2.     public static void main(String[] args) {  
3.         FactoryBMW320 factoryBMW320 = new FactoryBMW320();  
4.         BMW320 bmw320 = factoryBMW320.createBMW();  
5.   
6.         FactoryBMW523 factoryBMW523 = new FactoryBMW523();  
7.         BMW523 bmw523 = factoryBMW523.createBMW();  
8.     }  
9. } 

    工廠方法模式使用繼承自抽象工廠角色的多個子類來代替簡單工廠模式中的「上帝類」。正如上面所說，這樣便分擔了對象承受的壓力；並且這樣使得結構變得靈活 起來——當有新的產品產生時，只要按照抽象產品角色、抽象工廠角色提供的合同來生成，那麼就能夠被客戶使用，而沒必要去修改任何已有 的代碼。能夠看出工廠角色的結構也是符合開閉原則的！