創造類模式分為三種：簡單工廠模式，工廠模式和抽象工廠模式。
簡單工廠模式：用一個單獨的類來做創造執行個體的過程。
工廠模式：一個用于建立對象的接口，讓子類決定執行個體化哪一個類，講一個類的執行個體化
延遲到其子類。
抽象工廠模式：為建立一組相關或互相依賴的對象的類，而不指定具體類。
這是簡單工廠的結構圖，從圖中就很好了解。
簡單工廠的優點：
根據使用者需要，new出需要的對象。
但是簡單工廠弊端：
當新加入一個功能是，就要修改工廠。這個時候，就需要工廠模式了。
從圖中我們可以看出：
工廠模式客服了修改工廠類，運用擴充，加一個算法工廠，就行了。
工廠模式的有點：典型的解耦和模式。
這個就是抽象工廠，最核心的思想就是：抽象出接口類和抽象類，實作化不同的子類。
在資料庫通路中，在SQLserver中有User和Department兩張表，在Access中也有同樣的
同樣的兩張表，現在，需要向不同的資料庫中代碼通路User表，進行添加資料和查詢資料的方法。
分析：
怎樣做到最高效率的在SQLServer和Access中進行轉換時我們需要考慮的。
用戶端：
從代碼中我們可以看到，如果我們需要從Access資料庫中通路User，則要添加類，修改用戶端的代碼将SqlserverUser su=new SqlserverUser();這句代碼改為SqlAccessUser ac=new SqlAccessUser();這樣寫就違反了開閉原則。
接口層
上面是兩個接口，上面有他們的結構圖，一目了然。工廠接口是工廠方法模式的核心，與調用者直接互動用來提供産品。産品接口是定義産品的規範，所有的産品實作都必須遵循産品接口定義的規範。産品接口是調用者最為關心的，産品接口定義的優劣直接決定了調用者代碼的穩定性。
實作：
工廠的實作：工廠實作決定如何執行個體化産品，是實作拓展的途徑，需要有多少中産品，就需要有多少個具體的工廠實作。
用戶端：
若要通路Department表，設計到2維操作，我們需要用到抽象工廠：
這裡其實很簡單，就是加一個Department接口，兩個子類繼承，加一個實體類，修改工廠類。
由于代碼千篇一律，怕大家看煩了，就不曬了。
結構圖：
用戶端：
以上就是場景分析。
簡單工廠、工廠、抽象工廠是層層遞進的關系，但是都存在這有點和缺點，我都在裡面說了，是以，這裡僅簡單介紹一下抽象工廠的優點：
第一：易于交換産品系列，在一個應用中值需要再初始化的時候，出現一次，這就是的改變一個應用的具體工廠變得非常容易，他隻需要改變具體工廠即可使用不同的産品配置。
第二：讓具體的建立執行個體過程與用戶端分離，用戶端是通過他們的抽象接口操縱執行個體，産品的具體類名也被具體工廠的實作分離，不會出現在客戶代碼中。