小菜學設計模式——抽象工廠模式

背景

    簡單工廠、工廠方法模式，接着必須學習抽象工廠模式

一、使用意圖   

    擴展工廠方法模式

二、生活實例

    淘寶電影、貓眼電影都能爲咱們生成當天各類電影票

三、Java 例子（框架、JDK 、JEE）

    我的以爲實實在在的根據抽象工廠模式定義的類應該會不多，畢竟不方便擴展，雖然它是一種很了不得的思想。通常都會採用反射機制+抽象工廠完成，好比，JDBC模塊，在使用DriverManger.getConnection 這一步以前，必需要先加載驅動，也就是 Class.forname(class);這裏指定class，經過這一步就能夠建立驅動實例，也就是經過反射和工廠模式爲應用注入了對象；Spring 核心之一 IoC 採用的也是反射機制+工廠模式來完成。

四、模式類圖

  

五、模式優勢

    抽象工廠模式：提供一個建立一系列相關或相互依賴的對象的接口，而無需指定他們的具體類。

    最大的優勢是：容易交換產品系列，在一個應用中只須要在初始化的時候出現一次，這就使得改變一個應用的具體工廠變得很是容易，他只須要改變具體工廠便可使用不一樣的產品配置。

    其次，他讓具體建立實例過程與客戶端分離，客戶端是經過他們的抽象接口操做實例，產品的具體類別也被具體工廠實現分離，不出如今客戶端代碼中。

六、與相似模式比較

    咱們知道簡單工廠模式（靜態工廠模式）就是簡單的把對象的建立過程移到了工廠當中，經過對客戶端傳入的參數flag進行判斷生成對應的product對象；具體類圖以下：

這個模式最大的優勢是把對象生成的複雜邏輯與客戶端進行分離，這些邏輯判斷統統交給了工廠，因此缺點也很明顯，只要新增一種產品，他就須要修改工廠裏面的邏輯判斷；

    接着，工廠方法模式則是簡單工廠模式的一種改進，他把生成對象的邏輯判斷移到客戶端，有客戶端本身來決定初始化哪一個須要的類，那麼，當你須要新增一種產品時，只須要新增一個工廠類，就能夠達到目的，這樣克服了簡單工廠模式違背的開放封閉原則。具體類圖以下：

當你須要，新增一種產品時，就能夠經過新增一個ConcreteFactory類實例化一個ConcreteProduct，客戶端則更具本身須要來選擇具體的ConcreteFactory。相比簡單工廠，能夠這麼說，工廠方法模式其實就是增長了工廠。

    而後，就是抽象工廠模式，抽象工廠模式是在專門的條件下生成，比較簡單工廠和工廠模式能夠知道，他們生產的對象都有一個共同點，那就是生產的對象都是Product的子類，這些對象都是一類產品。但是若是我還想生成不是Product子類的產品怎麼辦呢？那麼，抽象工廠模式就是在工廠方法模式上擴展，把createProduct新增擴展爲CreateProductA和CreateProductB，甚至更多！就能夠生成ProductA的子類，也能夠生成ProductB的子類了。由於ProductA的子類可能有不少，因此 ConcreteFactory也就會有不少，並且ProductA和ProductB通常都是同屬一個家族。最後，你發現若是須要新增ProductC時，這個擴展起來可真不容易........

    最後，抽象工廠模式就是工廠方法模式的擴展，工廠方法模式就是簡單工廠的改進。

本文參考：

http://my.oschina.net/sunchp/blog/363483