1.抽象工廠的定義
-
抽象工廠(Abstract Factory)模式是所有形態的工廠模式中最爲抽象和最具一般性, 也最複雜的一種形態。
-
爲了方便描述抽象工廠模式,首先引進一個新概念:產品族(Product Family)。所謂產品族,是指位於不同產品等級結構,功能相關聯的產品組成的家族。如圖:
-
所謂的抽象工廠是指一個工廠等級結構可以創建出分屬於不同產品等級結構的一個產品族中的所有對象,**通俗的說,就是一個具體工廠創建一個產品族中的所有對象。**如果用圖來描述的話,如下圖:
2.角色與結構
- 抽象工廠(Abstract Factory)角色:擔任這個角色的是工廠方法模式的核心,它是與應用系統業務邏輯無關的接口(給出創建同一個系列多個對象的多個方法的聲明) 。
- 具體工廠(Concrete Factory)角色:這個角色直接在客戶端的調用下創建同一系列多個具體產品的實例。這個角色含有選擇合適的產品對象的邏輯,而這個邏輯是與應用系統的業務邏輯緊密相關的(實現具體的創建方法)。
- 抽象產品(Abstract Product)角色:擔任這個角色的類是工廠方法模式所創建的具體對象的父類,或它們共同擁有的接口—給出產品對象業務上的共同點,與業務邏輯相關
- 具體產品(Concrete Product)角色:抽象工廠模式所創建的任何產品對象都是某一個具體產品類的實例。這是客戶端最終需要的東西,其內部一定充滿了應用系統的業務邏輯。
3.示例
要求:
更換數據庫,項目其他部分不變,只是底層數據庫需要更換,如: 從Access更換爲SQL Server,將來還有可能更換爲Oracle…
SQL Server 與 Access的不同之處:
命名空間不同:Sytem.Data.SqlClient, System.Data.OleDb
獲取日期: GetDate(), Now()
獲取子字符串操作: SubString, Mid
Access要求Insert後面必須加into, 類似password這樣的關鍵字作爲字段名時必須用”[]”括起來。
注意看一下這個地方的源碼
4.優缺點
- 抽象工廠模式最大的好處便是易於更換產品系列,由於具體工廠類在每個應用中只需要在初始化的時候出現一次,這就使得改變一個具體應用的具體工廠非常容易,只需要改變具體工廠即可使用不同的產品配置。
- 我們的設計不能去防止需求的更改,因此我們的理想便是讓改動變得最小。
- 抽象工廠模式讓具體的創建實例的過程與客戶端分離,客戶端通過它們的抽象接口操縱實例,產品的具體類名,不會出現在客戶端代碼中----具體類名也被具體工廠實現分離(客戶端程序沒有出現具體的Access或SQLServer操作類的名字)
- 但是如果變化的不是產品系列而是產品(如:上例中的表操作—表的個數-產品等級結構- 或 表操作的個數),則抽象工廠模式封裝的變化點就有問題了(開放-封閉原則的傾斜性)–抽象類應該穩定,無論何種原因導致的抽象類被頻繁修改,都應該引起重視!!!
- 如果具體工廠的創建語句在程序中大量出現,則抽象工廠模式也不適合採用。
- 也可以用反射解耦
我尋思這應該不是重點