前一篇降到了簡單工廠模式,也提到了簡單工廠模式的缺點:違背了**六大設計原則之一的開放封閉原則。為了解決這個問題,於是又引出乙個新的設計模式:工廠方法模式。
* 工廠方法模式(factory method partten)*:定義乙個抽象類(對某個產品的抽象),讓子類去繼承實現乙個具體的產品。同時定義乙個抽象的工廠類,每個具體的產品對應乙個具體的工廠類,在工廠類中建立產品的例項。 說簡單一點,就是在簡單工廠的基礎上, 工廠類不再是乙個類了,而是有乙個抽象類,然後有多少產品,就再實現多少個對因的工廠類。 uml用例圖如下:
比如, 在簡單工廠中實現的示例**中, 我們講到了加減乘除法, 我們繼續講這個例子, 用抽象工廠去實現後, 它的uml用例圖如下:
在這個例子中,工廠類不再是乙個,而是加法對應了乙個加法工廠類, 減法對應了乙個減法工廠類。
簡單工廠的**為:
ioperation ope = ******factory.create(******factory.add);
int result = ope.getresult(6,3);
使用工廠方法後, 業務**變成了這樣:
ifactory factory = new addfactory();//建立對應計算方法的工廠類
ioperation ope = factory.create();
int result = ope.getresult(6,3);
仔細一看, 可能產生了疑問?這不就是把簡單工廠裡的分支判斷直接挪到了業務**的地方嗎?
其實並不完全是這樣, 在簡單工廠中我們提到, 如果分支太多, 就不太好維護和管理了,乙個工廠類也會顯得過於臃腫,萬一某個類的例項化需要修改, 我們都得進入這乙個工廠類來修改,要是改錯了就不好了, 有潛在風險, 同時, 這種設計也不符合**設計六大原則之單一職責原則和開放封閉原則。於是, 通過工廠類進一步的抽象, 可以獲得以下好處:
缺點主要就是**量和類的數量整體上公升了。
所以,我們實際開發過程中,也是要兼顧**優化和開發效率的, 有些比較簡單,用的的地方少,也沒幾個分支,**結構不負責的,直接使用簡單工程模式就行了,反之, 則可以考慮使用公升級版的工廠方法模式了。
設計模式 工廠方法模式
一 工廠方法 factory method 模式 工廠方法模式的意義是定義乙個建立產品物件的工廠介面,將實際建立工作推遲到工廠子類當中。核心工廠類不再負責產品的建立,這樣核心類成為乙個抽象工廠角色,僅負責具體工廠子類必須實現的介面,這樣進一步抽象化的好處是使得工廠方法模式可以使系統在不修改具體工廠角...
設計模式 工廠方法模式
1 factorymethod.h ifndef factorymethod h define factorymethod h include include using namespace std class osproduct 產品,product,產品的抽象類 class windowspro...
設計模式 工廠方法模式
框架的基礎知識 對框架的理解 框架和設計模式的關係 工廠方法模式 定義 定義乙個用於建立物件的介面,讓子類決定例項化哪乙個類,factory method使乙個類的例項化延遲到其子類。結構 產品 public inte ce product 具體產品 public class productimpl...