抽象工廠模式：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
抽象工廠模式最大的好處便是易於交換產品系列，由於具體工廠類，例如IFactory factory=new AccessFactory(),在一個應用中只需要在初始化的時候出現一次，這就使得改變一個應用的具體工廠變得非常容易，它只需要改變具體工廠即可使用不同的產品配置。我們的設計不能去防止需要的變更，那麼我們的理想便是讓改動變得最小，那麼現在如果你要更改數據庫訪問，我們只需要更改具體工廠就可以做到。
第二大好處是，它讓具體的創建實例過程與客戶端分離，客戶端是通過他們的抽象接口操縱實例，產品的具體類名也被具體工廠的實現而分離，不會出現在客戶代碼中。
實際上，我們第二回合中的代碼中，客戶端所認識的只有IUser和IDepartment，至於它是用Sql Server來實現還是Access來實現就不知道了。
但是接下來的問題是，如果我們再添加一個項目表Project，該怎麼辦？
首先要增加三個類，IProject,SqlServerProject,AccessProject,還需要更改IFactory、以及SqlServerFactory和AccessFactory才可以實現。
現在我們要對上面的關系代碼進行整改，需要前面的簡單工廠模式。http://www.cnblogs.com/aehyok/archive/2013/05/10/3072008.html
db=
=== ===
原先一個接口，兩個接口的實現，現在我們用一個DataAccess類就可以來代替了。
客戶端調用方法也有所改動
==
現在選擇那個數據庫是在DataAccess中定義的 db=當然更好的辦法實在配置文件中進行變動就可以了。
如果如前言中所說 ，添加一個項目，那麼我們只需要在DataAccess類中添加雷同的方法即可。
但是還是有問題，前面我們也稍微提到過，比如現在有需求要用Oracle數據庫。原來只需要增加OracleFactory工廠就可以了，現在就比較麻煩了。
如果你還不太了解反射，那麼可以簡單的看一下我之前的一篇入門的反射博文http://www.cnblogs.com/aehyok/archive/2013/03/25/2963287.html
首先使用反射我們需要引用using System.Reflection來引用Reflection,就可以使用反射來優化抽象工廠模式的先天不足。
順便來看一下反射的簡單使用，來獲得實例的方法
IUser result = SqlServerUser(); ///這是常規的寫法
接下來看看用反射的寫法，別忘了首先要引用哦
IUser result = (IUser)Assembly.Load().CreateInstance();
那麼現在可以發現用了反射我們可以利用字符串來實例化對象，而變量是可以替換的，而常規的寫法都是寫死在程序裡的。
接下來看看我們用反射優化後的抽象工廠，其實也就是對上面DataAccess類進行的優化。
db = AssemblyName = ClassName = AssemblyName++db+= (IUser)Assembly.Load().CreateInstance( ClassName =+ +db+
其實這裡我們還可以簡單的優化一下，就是用配置文件
<?xml version= key= value= key= value= sku=/></startup></configuration>
db = ConfigurationManager.AppSettings[ AssemblyName = ClassName = AssemblyName++db+= (IUser)Assembly.Load().CreateInstance( ClassName =+ +db+
這樣需要什麼數據庫，只需要在配置文件當中進行配置即可。
所以，所有在用簡單工廠的地方，都可以考慮用反射來去除switch或if，接觸分支判斷帶來的耦合。
原來通過抽象工廠可以學到這麼多的知識很好，要多多吸收才可以。
最終版本的抽象工廠模式實例代碼下載鏈接為http://url.cn/GgWA2K
