設計模式（創造型）一

標籤：style   blog   http   color   使用   ar   strong   2014   div   

設計模式（創造型）

目錄

•  創造型設計模式整合(建造者模式+原廠模式/靜態工廠+抽象原廠模式)創造模板的實現
•  簡單工廠
•  原廠模式
•  抽象原廠模式
•  建造者模式
•  原型模式
•  單例模式（下一篇講解）

 

吐槽：周末+中秋+生日，為了明天而在家寫代碼的有木有。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

         擦，這台電腦居然沒裝Eclipse，只能手寫了。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

一 、創造型設計模式整合(建造者模式+原廠模式/靜態工廠+抽象原廠模式)創造模板的實現

個人概括：創造型的設計模式一般是用來為業務層或者邏輯層提供底層實現類初始化策略的設計思路。

簡單來說：就是用來建立對象的模式。

 

本次整合我使用的策略：

   抽象原廠模式：用於創造對象

   建造者模式：用於初始化對象

   原廠模式/靜態工廠：用於對建造者模組再次抽象（此處的代碼在簡單工廠中會有描述）

具體步驟：                          

情境準備： 一堆雜亂的實作類別 (A1,A2,A3) (B1,B2,B3) (C1,C2,C3)

整體的設計步驟 -> 1 對實作類別進行抽象，抽象出通用特性（這是創造型設計模式的核心）

                         （A1，A2，A3）抽象出介面A、(B1,B2，B3)抽象出介面B。。。。。。。

                         2 定義一個或多個介面裡面有個方法用於擷取第一步抽象出的A,B,C介面的子類....

                         interface ManagerService { public A getAInstance();

                                                                public B getBInstance();

                                                                public C getCInstance();

                                                                ....

                                                              }                    

                        3 編寫ManagerService介面的實作類別Factory1,Factory2,Factory3;

                        4 每個Factory在實現getInstance方法的時候，可以自由搭配不同的實作類別，比如

                            @override

                             public A getAinstance(){

                                    return new A1();//return new A2();

                            }------到此就是原廠模式的架構

                          /** 擴充代碼--用於初始化NEW出對象的屬性

                                通過了這一層的封裝，最重要的不僅僅是為了NEW 一個實作類別A1，B2，C1...

                                而是為了更多的擴充：對接初始化對象的屬性的擴充。

                                1 定義一個介面使用者build對象屬性

                                 interface Builder{

                                          public A bulid();

                                 }

                                2 實現介面Builder類BuilderSampleA,BuildSampleB

                                @overrider

                                BuilderSampleA{

                                      A a;

                                     public BuilderSampleA(A a){this a = a;}

                                     public A bulid(){

                                         a.setxxx

                                         a.setxxx

                                         ....

                                    }

                                }

                               3 定義一個控制類Create用於控制需要初始化的方式,他接收Build的實現子類

                                  public class Create {

                                     public Object execute(Builder b){

                                           return  b.build();

                                     }

                                  }

                                4 每個Factory在實現getInstance方法的，可對比上面擴充代碼之前的實現      

                                  @override

                                      public A getAinstance(){

                                       //    return new A1();

                                              Create c = new Create(new BuilderSampleA(new A1()); //這個工廠就是初始化A1的，所以這裡可變的只有Builder的子類，而這個SamplerA的Builder利用上述方法也可以進行繼續抽象和工廠化

                                              return c.execute()                                                                    //但個人建議到了這個層面似乎可以考慮用靜態工廠的方式比較好，畢竟初始化的參數得策略並不會太多，這裡就不再擴充了。

                                        }

                           **/

                        5 用戶端的調用過程-最小知道原則：暴露ManagerService介面以及具體的完成調用的工廠即可

                            樣本這是創造A1實作類別的過程。比如Factory1,2,3分別對應了A1,2,3

                           ManagerService manager = new Factory1();//無論創造哪一種A的實作類別，只有這裡標紅的地方是需要修改的。

                                               A a =  manager.getAInstance(); 

                         /** 擴充後其實對於用戶端來說也是一樣的，或許getAInstance(String type)方法的入參會有所不同,通過type來選擇哪一種sampler

                                     ManagerService manager = new Factory1();

                                               A a = manager.getAinstance(“samplerA”);

                         **/

 

 看完了UML圖後，現在我們來拆分整個創造型模式的各種策略

                 

二、簡單工廠

 

 

圖片摘自百度百科

 

step 1 對底層實作類別進行抽象成一個公用的介面

step 2 編寫一個建立執行個體的控制層，根據入參的不同NEW出不同的實作類別

 這裡我給出一段靜態工廠類的示範（又要手寫，累死了），其他的其實可以參照上面的整合版本來看。(補充了對BuilderSampleA，B，C選擇的問題了)    public class Factory{             public static Creator(String type)//這裡可以用反射來實現            {                   if(xxx.equals(type))                            return  new BuilderSampleA(new A1();                   if(yyy.equals(type))                            return  new BuilderSampleB(new A1();               }   }

 

 個人評價

優點：靜態Factory 方法的實質是將用戶端的邏輯封裝到了服務端，對於代碼而言確實是少了很多，當邏輯不多並且相對穩定不變的情況下，這樣的策略還是很不錯的。

缺點：缺點也很明顯，當邏輯複雜時，代碼的可讀性並不高（大量的IF/else）,另外如果每次新增一項業務時，需要對類的內部進行修改，嚴重違反開閉原則。

解決方案：可通過原廠模式解耦商務邏輯，一個IF就是一個工廠類，然後根據工廠類抽象出一個管理工廠的介面。用戶端只需要知道管理工廠的介面與工廠類即可。

 

三、原廠模式

 圖片摘自左瀟龍部落格

 

step 1 對底層實作類別統一抽象出一個介面

step 2 定義一個工廠管理介面，用於統籌的NEW 出實作類別

step 3 根據業務情境的數量製造對應的工廠類去實現工廠管理介面NEW出具體的底層實現（相當於把簡單工廠裡面的IF/ELSE變成了一個一個的類從而解耦商務邏輯）

step 4 由於工廠類是負責管理NEW的過程，也可以理解為封裝的過程，所以這裡可以再引入--建造者模式

個人評價：非常不錯的的封層思想，通過工廠的封層使得類的初始化變得更為方便了。

缺點：暫沒有想到，工廠類和產品類可能會很多，但是我覺得是必要的。

 

四、抽象原廠模式

 

 

這裡的步驟我就不再細緻寫了

等同於原廠模式，唯一的區別在於介面不再是單一方法，所以工廠生產的是一套組件。

個人評價 等同於原廠模式。

 

 

五、建造者模式

 

 

建造者模式是針對實體類進行屬性的初始化

step 1 定義一個Builder介面

step 2 實現Builder介面的類其實就是一個個初始化參數的策略

step 3 建立一個Creator類用於統一管理Builder的子類，

其實到這裡step 2 就可以了用戶端是 Builder b = new BuilderSampleA(A a); b.build(); 這樣完成了調用。

如果寫了step 3，用戶端就是 Creator c = new Creator(new BuilderSampleA(A a));c.execute();

不知道大家是否能明白為什麼要Creator呢？

答：其實我個人理解是為了再次封裝。參照靜態Factory 方法裡面的樣本。

 

六、原型模式

原型模式我已經很少用了，大致是繼承Cloneable介面，然後使用父類的Object的clone方法吧。

如果是深度複製，那麼下一層的對象也需要重寫。

所以複雜物件用這方式並不方便，或許有更好的策略吧關於clone方法上的。

 

我是用JSON方式來完成複製的，蠻方便的。

Object-->Json--->Object

 

 

 

 

主要的參考資料：

大話設計模式

百度百科

 http://www.cnblogs.com/zuoxiaolong/p/pattern26.html

設計模式（創造型）一