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