由於博文僅傾向於模式的理解與相似模式間關係，所以，博文可能會以某類模式一起論述的形式出現。這些主要是個人回顧性的總結，具有較強的隨意性，必定存在論述上的不周或過於累贅，還望朋友們海涵指正。

      我們知道設計模式的最基本的原則是狀態變化部分和不變部分儘可能地分離，比如橋接（Bridge）模式採用的是抽象和抽象的實現分離，這種分離想達到的效果就是較好的複用，就是對開-閉原則的最大限度支援。我們學習模式，為的就是理解模式，充分重用前輩經驗，站在巨人的肩膀上，為設計出好的設計找尋方法。

      由GOF整理的23種設計模式共分三大類：建立模式、結構模式和行為模式。

      人們往往認為最為簡單的就是建立模式，也許是因為日常工作中涉及到的機會更多些，尤其是工廠類模式，若有面試時一般情況下面試官會說除工廠類模式之外請你介紹下你較為熟悉的模式。不過，在建立模式中，單例（Singleton）模式卻是常被拿來作為筆試考察的，側重於單例模式的實現（所謂的餓漢、懶漢、註冊、雙重檢查等實現方式優劣以及多類載入器、多JVM情況下Singleton的表現）及其使用場景。

      儘管建立模式被認為相對簡單，但加深對它們的認識還是必要的。建立模式，它抽象了類的例項化過程，針對類，使用繼承改變了真正被例項化的類，針對物件，則會將物件例項化委託給另一個物件。從該角度看，建立模式利用繼承和引用的方式來完成需要的各種物件的建立工作，把和物件的建立相關的事務統一進行處理，並通過建立不同類別的物件來應對資訊系統外部的變化，為系統提供靈活性。當系統的靈活性不是依賴於多型繼承機制，並隨著系統演化得越來越依賴於物件的複合，建立模式變得更為重要，甚至成為系統靈活機制的核心，原因就在於建立模式可以通過委託方式來滿足這一需求。

      建立模式包含有簡單工廠（SimpleFactory）模式、抽象工廠（AbstractFactory）模式、建造者（Builder）模式、單例（Singleton）模式和原型（Prototype）模式，以下篇幅的介紹物件是簡單工廠模式、抽象工廠模式、建造者模式以及由工廠和抽象工廠引出的工廠方法模式，單例和原型將在以後篇幅給予闡述。

      #簡單工廠（SimpleFactory）模式：又稱靜態工廠方法模式，是由一個工廠物件決定創建出哪一種產品的例項。下圖是工廠模式的一般性示意圖：

      從示意圖中我們可以看出該模式的優點是客戶端Client無需關心產品的建立，建立責任有核心的工廠類Factory負責；而缺點是核心的工廠類Factory必須知道要建立哪一類產品及如何被建立，尤其是當產品類有不同的介面種類時，核心的工廠類Factory需要判斷何時生產何種商品，使得系統將來擴充套件比較困難。因此，該模式此時對“開-閉”原則的支援度為有限支援，即不影響客戶端，但需要維護工廠自身邏輯。

      關於實現，我們首先看Product，它應該是抽象類呢還是介面呢？

      這個問題其實在關於模式中曾提到過的，並給出了個人認為較為合適的答案。答案的核心在於是否需要多繼承及是否彼此間有相同的商業邏輯需要共享進行程式碼上移。一般情況下推薦使用介面（現代開發最佳實踐面向介面程式設計），這裡給出幾種具體場景的個人認為該使用何種方式的答案。其一是可能需要多繼承，此時，Product此時均應為介面，若有此種情況同時兼有商業邏輯需要共享，則遵循程式碼上移的原則，可再抽象出一層AbstractProduct實現Product介面完成此使命，若在關於模式中舉的水果和蔬菜的例子，它們各自有共享商業邏輯程式碼的需要，同時又存在多繼承的可能性（蔬菜的西紅柿變身水果）；其二是不存雜多繼承，但需要共享商業邏輯程式碼，Product應為抽象類。

      其次看核心的工廠類的工廠方法，若該工廠只負責生產一種產品型別，藉助java反射是完全可以做到完全支援“開-閉”原則的，即增加新產品不會影響原有系統功能，如下實現說明：

1. //不完全支援開-閉原則的實現，因為if...else模式使得新加入產品時需要維護Factory  
2. public class Factory {  
3.    public static Product factory(String which) {  
4.        if(which.equalsIgnoreCase("product1") ){  
5.            return new ConcreteProduct1();  
6.         } else if(which.equalsIgnoreCase("product1")) {  
7.            return new ConcreteProduct2();  
8.         } else {  
9.            throw new RuntimeException("the product type doesn't exist");  
10.         }  
11.     }   
12. }  
13. //完全支援開-閉原則，因為java反射消除了新增產品對Factory的維護  
14. public class Factory {  
15.    public static Product factory(String productpath) {  
16.        try{  
17.           return (Product) Class.forName(productpath).newInstance();  
18.        }catch(Exception e){  
19.           throw new RuntimeException("the product type doesn't exist");  
20.        }  
21.    }  
22. }  

      若該工廠負責生產至少兩種產品型別，則該簡單工廠模式只能保持它對開-閉原則的不完全支援，因為，核心的工廠類Factory需要判斷何時生產何種商品，不免會因產品的增加而需要維護工廠自身邏輯。對於這種產品族工廠生產需求，為了滿足對開-閉原則的支援需要使用後面將要介紹的抽象工廠模式。

      這裡稍微提一下針對抽象（介面）程式設計，針對抽象程式設計--利用具體產品類的超類型別，將它的真實類隱藏起來。其優點是提供了系統的可擴充套件性。（若將來有新的具體子類被加入到系統中來，那麼工廠類可以將交給客戶端的物件換成新的子類例項，而對客戶端無任何影響）這種將工廠方法的返回型別設定成抽象產品型別的做法，叫做針對抽象程式設計，這是依賴倒轉原則（DIP）的應用。

     最後，我們來看一下針對簡單工廠方法在單產品和產品族下存在的更好的模式，即工廠方法和抽象工廠。

     #工廠方法（FactoryMethod）：把物件的建立延遲到子類中進行，其核心是在父類和子類之間分配建立的責任，即把原先應該有父類直接完成的事情交給子類去做。

     工廠方法與產品存在層對應關係，一般的工廠方法模式示意圖如下：

      由上面工廠方法的示意圖我們可以看出工廠方法與簡單工廠有如下幾點關係：1、結構上明顯不同。工廠方法的核心是一個抽象工廠類（XCreator），簡單工廠模式把核心放在一個具體類上。2、工廠方法模式保持了簡單工廠模式的優點，且客服了它的缺點。簡單工廠模式中，一個工廠類處於產品類例項化的中心位置上，它知道每一個產品，決定哪一個產品應當被例項化，存在一定的優缺點；工廠方法模式是簡單工廠模式的進一步抽象和推廣。因使用了多型性，工廠方法模式保持了簡單工廠模式的優點，且客服了它的缺點。工廠方法模式中核心的工廠類不再負責所有產品的建立，而是將具體的建立工作交給了子類去做，這個核心類則搖身變為了一個抽象工廠角色，僅負責給出具體工廠子類必須實現的介面，而不接觸哪一個產品類應當被例項化這種細節。這種進一步抽象的結果，使得工廠方法模式允許在不修改具體工廠角色的情況下引入新的產品，遵循“開-閉”（實指單產品下相比SimpleFactory的if...else實現模式）。

     為了更加直觀的對該模式產生認識，給出以下示例性程式碼： 

1. //client invoke sample  
2. public class Client {  
3.    private XCreator xConcreteCreator1,xConcreteCreator2;  
4.    private XProudct xConcreteProduct1,xConcreteProduct2;  
5.    public static void main(String[] args) {  
6.       xConcreteCreator1 = new XConcreteCreator1();  
7.       xConcreteProduct1 = xConcreteCreator1 .factory();  
8.       xConcreteCreator2 = new ConcreteCreator2();  
9.       xConcreteProduct2 = xConcreteCreator2 .factory();  
10.   }  
11. }  
12. //creator sample  
13. public interface XCreator{  
14.    public XProduct factory();  
15. }  
16. public class XConcreteCreator1 implements XCreator {  
17.    public XProduct factory() {  
18.       retrun new XConcreteProduct1();//maybe more complisity creating the product  
19.    }  
20. public class XConcreteCreator2 implements XCreator {  
21.    public XProduct factory() {  
22.       retrun new XConcreteProduct2();//maybe more complisity creating the product  
23.    }  
24. //product sample  
25. public interface XProduct{}  
26. public class XConcreteProduct1 implements XProduct {}  
27. public class XConcreteProduct2 implements XProduct {}  

        關於工廠方法的更好學習例項推薦參考java原始碼中迭代子實現，其結構示意圖如下圖左，工廠方法的一般性排程流程示意圖如下圖右:

       實際上，使用工廠方法FaintMethod的核心根源並不在於僅僅把物件的建立延遲到子類中，那只是處理方法。使用的原則是客戶物件需要處理很多的某種子類物件，客戶物件面臨兩個問題，一個是選擇建立哪一個子類的物件，一個是被選定的子類物件如何人被建立。但是這兩個邏輯，工廠方法模式把他們分開了。在模式之外選擇建立哪一個子類物件，而在具體建立這個物件的時候，又使用工廠類的子類來遮蔽建立的這個子類物件的特殊性。這樣，客戶就可以獨立於需要使用的子類物件的變化而始終保持穩定了。 理解工廠方法的時候，需要認識到工廠方法的子類僅僅是遮蔽了產品子類建立的不一致性，而具體選擇哪一個產品則是外部邏輯提供的。工廠方法的價值在於，產品物件的建立和初始化的不同被遮蔽了，因此，如果子類物件的建立方法沒有大的不同，那麼使用工廠方法模式是無價值的。

      #抽象工廠（AbstractFactory ）模式：抽象工廠引入產品簇的概念（工廠與產品存在層次結構）！該模式是所有形態的的工廠模式（簡單工廠、工廠方法、抽象工廠）中最為抽象&最具一般性（如下圖，左邊代表工廠，右邊代表不同產品形成的產品簇，而右圖是一般性的實現）。該模式用意是向客戶端提供一個介面，使得客戶端在不必指定產品具體型別的情況下，建立多個產品簇中的產品物件。

     上圖展示了由ProductA、ProductB為類別的兩類產品，存在簇1{ProductA1，ProductB1}和簇2{ProductA2，ProductB2}，並分別有工廠ConcreteCreator1和ConcreteCreator2負責建立，為了更直觀展示給朋友們形成感性認識，下面給出示例性程式碼：

1. public interface Creator {  
2.     public ProductA fatoryA();  
3.     public ProductB factoryB();  
4. }  
5. public class ConcreteCreator1 implements Creator {  
6.     public ProductA factoryA() {  
7.            retrun new ProductA1();  
8.     }  
9.     public ProductB factoryB() {  
10.            retrun new ProductB1();  
11.     }  
12. }  
13. public class ConcreteCreator2 implements Creator {  
14.     public ProductA factoryA() {  
15.            retrun new ProductA2();  
16.     }  
17.     public ProductB factoryB() {  
18.            retrun new ProductB2();  
19.     }  
20. }  
21. public interface ProductA {}  
22. public class ProductA1 implements ProductA {  
23.     public ProductA1(){}  
24. }  
25. public class ProductA2implements ProductA {  
26.     public ProductA2(){}  
27. }  
28. public interface ProductB {}  
29. public class ProductB1 implements ProductB {  
30.     public ProductB1(){}  
31. }  
32. public class ProductB2implements ProductB {  
33.     public ProductB2(){}  
34. }  

        在上面闡述簡單工廠（SimpleFactory）模式時曾提及對於產品族需求的工廠，簡單工廠（SimpleFactory）模式無法很好的支援開-閉原則，那麼，抽象工廠（AbstractFactory）模式對開-閉原則的支援度到底又如何呢？簡單地說，是有選擇的完全支援。在產品等級結構的數目不變的情況下，增加新的產品族，對原有系統不會造成任何影響，此時是完全支援開-閉原則。然而，在產品族的數目不變的情況下，加新的產品等級結構，則原有系統實現的FactoryMethod都應做相應的調整，此時是處於不支援開-閉原則狀態的。

        關於何時應該考慮使用抽象工廠，前人總結了以下幾點：1、一個系統不應當依賴於產品例項如何被建立、組合和表達的細節，這對於所有形態的工廠模式都是重要的。2、系統擁有的產品有多餘一個的產品族，而系統只消費其中某一族的產品。（與抽象工廠的起源有關）3、同屬於同一個產品族的產品是在一起使用的，這一約束必須在系統的設計中體現出來。4、系統提供一個產品類的庫，所有的產品以同樣的接口出現，從而使客戶端不依賴於實現。

       以上這幾點在抽象工廠（AbstractFactory）模式的起源中有很好的體現，其實，抽象工廠起源於跨作業系統的產品實現，通過下圖的拋磚引玉，相信大家已不言自明瞭：

      #建造者（Builder ）模式：將一個產品的內部表象與產品的生產過程分離，從而可以使一個建造過程生成具有不同內部表象的產品物件。若我們把工廠模式看做現實世界的生產車間，負責某種產品的建立工作，那麼我們可以把建造者模式看做是組裝車間，負責產品組裝形成相對複雜的產品。比如採用Builder模式來生成汽車，我們便可以用工廠方法生產汽車所需的各類部件（輪胎、車燈、方向盤、發動機等等），然後由Builder負責組裝成最終產品汽車。下圖是通用性的Builder模式示例圖：

       這樣以來，我們便可以看到簡單工廠模式、工廠方法、抽象工廠模式與建造者模式它們之間的一些關係與側重點。簡單工廠模式負責產品的建立，使得客戶端無需關心產品的建立過程，工廠方法是針對簡單工廠模式存在的缺點（不完全支援開-閉原則，增加新產品雖不影響客戶端，但需要維護簡單工廠邏輯）而引入的，抽象工廠模式引入了產品族的概念，是工廠模式的進一步擴充套件，而建造者模式則更側重於複雜產品的生產，期間可以利用工廠模式完成builderPart工作。

      以下是使用建造者模式幾種場景以及期待達到的效果。

      場景：1、需要生成的產品物件有複雜的內部結構。（工廠各車間：每個內部成分本身可以是物件，也可以僅是產品物件的一部分，自身並不構成物件概念）
               2、需要生成的產品物件的屬性相互依賴。（工廠流水線：builder模式可以強制實行一種分步驟進行的建造過程，因此，若產品物件的一個屬性必須在另一個屬性被賦值之後才可以賦值，使用builder模式便是一個很好的設計思想）
               3、在物件建立過程中會使用到系統中的其它一些物件，這些物件在產品的建立過程中不易得到。
      效果：使用builder模式主要有以下效果：
              1、builder模式的使用使得產品的內部表象可以獨立地變化。客戶端不必知道產品內部組成的細節。
              2、每一個builder都相對獨立，與其它的builder無關。
              3、模式所建造的最終產品更易於控制。

      在這裡我們著重看下建造者（Builder）模式與工廠（Factory）（主要是AbstractFactory）模式間的關係。兩者很相似，都是用來建立同時屬於幾個產品族的物件的模式。不同之處在於--AbstractFactory模式中（相對簡單產品），每一次工廠物件被呼叫時都會返回一個完整的物件，至於client如何處理該物件與工廠自身無關；Builder模式（相對複雜產品，側重產品組裝流水），它則是一點一點地建造出一個複雜的產品，而這個產品的組裝過程就發生在builder角色內部。這兩種模式，AbstractFactory更加微觀，而Builder更加巨集觀。一個系統可以由一個bulider和一個AbstractFactory組成，client通過呼叫這個builder角色，間接地呼叫另一個AbstractFactory角色，AbstractFactory模式返還不同產品族的零件，而Builder模式則把他們組裝起來。

     從某種角度來說，Build模式也是我們完成生產某種產品工作的策略，這不免會使我們想到策略（Strategy）模式。事實上，Builder模式是Strategy模式的一種特殊情況，而區別在於各自的目標不同。Builder模式適用於為client客戶端一點一點地建造新的物件，而不同型別的具體Builder角色雖然都擁有相同的介面，但它們所創建出來的物件可能完全不同；Strategy模式目的是為演算法提供抽象的介面，即利用里氏替換滿足“開-閉”，通過具體策略類封裝某演算法，不同的策略類物件為一種一般性的服務提供不同的實現。

     與此同時，我們看到Builder組裝產品的過程類似於模板（Template）模式，比如builder.builderPart1()-->builder.builderPart2()-->retrieveResult()這樣一條流水生產產品，事實上，失去Director角色後的Builder模式順理成章地發展到了Template模式。

     說到這裡，大家可能已經意識到模式間是存在關係的，這裡便涉及到如何區別與聯絡這些模式間關係的問題，在這裡，我給出一些個人建議。 首先要看模式的類別，一般來說，結構模式和行為模式服務於創造模式，創造模式和服務於客戶所需的最終產品。建立模式側重於產品的建立方法，結構模式側重於產品的結構間關係結構設計，行為模式側重於出於建立產品的目的，在創作過程中表現出的行為。其次要看各模式的目的及使用場景與達到的效果，這個過程主要是考察重用粒度與對開-閉原則的支援度，在關於模式中我們已經提到過，保障重用原則的是程式碼上移&資料下移，保障開-閉原則的是依賴倒轉、介面隔離、迪米特原則、里氏替換原則和組合/聚集，不再贅述。

       靜態內部類和構建者模式：

靜態內部類使用場景一般是當外部類需要使用內部類，而內部類無需外部類資源，並且內部類可以單獨建立的時候會考慮採用靜態內部類的設計，在知道如何初始化靜態內部類，在《Effective Java》第二章所描述的靜態內部類builder闡述瞭如何使用靜態內部類：

public class Outer {
    private String name;
    private int age;

    public static class Builder {
        private String name;
        private int age;

        public Builder(int age) {
            this.age = age;
        }

        public Builder withName(String name) {
            this.name = name;
            return this;
        }

        public Builder withAge(int age) {
            this.age = age;
            return this;
        }

        public Outer build() {
            return new Outer(this);
        }
    }

    private Outer(Builder b) {
        this.age = b.age;
        this.name = b.name;
    }
}

靜態內部類呼叫外部類的建構函式，來構造外部類，由於靜態內部類可以被單獨初始化說有在外部就有以下實現：

public Outer getOuter()
{
    Outer outer = new Outer.Builder(2).withName("Yang Liu").build();
    return outer;
}

對於靜態類總結是：1.如果類的構造器或靜態工廠中有多個引數，設計這樣類時，最好使用Builder模式，特別是當大多數引數都是可選的時候。

                               2.如果現在不能確定引數的個數，最好一開始就使用構建器即Builder模式。