<抽象工廠>比<工廠方法>多了啥（區別）

前言：僅當複習討論，寫得很差，多多指教!

上一篇文章《 <工廠方法> 比 <簡單工廠> 多了啥 》介紹了簡單工廠模式和工廠方法模式。本篇文章則講最後一個工廠----抽象工廠。若是對工廠方法比較模糊的，能夠返回上一篇文章複習。接下來先看故事。

抽象工廠模式

UML

  又通過三年以後，中國已經愈來愈國際化了，不少日本人來中國留學也帶來了本土的貓和狗。一旦他們留學回去以後，就把這些動物送到了動物流浪工廠中。此時，個別對小日本有抵觸的人並不想爲這些日本的動物餵食，因而拉起一部分人到工廠去抗議，要求本身的食物只給中國的動物吃，把日本的動物趕出去。廠長一看這麼多人抗議，沒辦法，只能把動物分國籍了，因而把中國流浪動物在一個工廠，日本流浪動物在另一個工廠。
  某一天，一位原本認爲日本的動物也是動物的愛心人士看到了安培晉三參拜靖國神社的新聞，因而她要求原來餵養的日本流浪動物 切換 到中國流浪動物，以下圖所示，她只要切換一個工廠就能夠達成心願。

對比一下業務場景

概念

  抽象工廠模式：爲建立一組相關或相互依賴的對象提供一個接口，並且無需指定他們的具體類。（如上圖，提供了數據庫抽象工廠，而無需指定具體數據庫給客戶端）

優勢

1. 最大的好處就是易於交換產品體系（sqlserver 替換成 oracle），因爲具體工廠類，例如sql server工廠在一個應用中只須要在初始化的時候出現一次，這就使得改變一個應用的具體工廠變得很是容易，它只須要改變具體工廠便可使用不一樣的配置。
2. 它讓具體的建立實例過程與客戶端分離，客戶單是經過它們的抽象接口操做實例，產品的具體類名也被具體工廠的實現分離，不會出如今客戶端代碼中（好比sqlserverUser, 客戶端只知道抽象類，不關心你是用sql server仍是用oracle來實現。所有都依賴抽象，符合依賴倒置原則）

缺點

1. 若是更換 產品體系，改動的工做量很是大，由於處處都有 IFactory factory=new SqlserverFactory()的實現。這麼實例化1000次，就要改1000次。
2. 增長一個功能，要涉及到增長三個類和修改三個工廠，這。。。比較累人。

改進

  針對以上兩個問題，來進行解決。1.可不可動態實例化？2. 增長類是可擴展的，可是修改三個工廠是否能夠去掉？

  答案是：能夠的，利用反射+配置文件

UML

  咱們將工廠幹掉，利用數據庫Context類來動態實例化具體的功能類（產品類）。利用反射來實例化相關的實例，而不是讓工廠去實例化，實例化格式以下：
  Assembly.Load(「程序集名稱」).CreateInstance(「命名空間.類名稱」)

客戶端實現方式

數據庫Context代碼以下：

class 數據庫Context
{
    private static readonly string db=ConfigurationManager.Appsettings["DB"];
    private static readonly string AssemblyName="程序集名稱"；

    public static IUser 增長用戶（）
    {
     string className=AssemblyName+".User";
     return  (IUser)Assembly.Load(AssemblyName).CreateInstance(className);
    }
  
//其餘相似
}

總結

介紹完了抽象工廠模，可是它跟工廠方法的差別在哪裏？

1. 每個模式都是針對必定問題的解決方案，工廠方法模式針對的是一個產品等級結構；而抽象工廠模式針對的是多個產品等級結構。
2. 工廠方法模式是必定要利用工廠抽象類的，這個是包含在它的定義中的。而抽象工廠模式進階中已經幹掉了抽象工廠類，去利用反射進行實例化。
3. 在實際項目中,更換數據庫是有可能的, 好比某個數據提供商數據量大的時候不夠穩定,此時通過商討,要更換數據提供商,這裏就涉及到很大的擴展性問題了。