設計模式(三) 工廠方法模式

2021-08-08 06:02:11 字數 3365 閱讀 7033

在設計模式——簡單工廠模式文章中介紹了簡單工廠模式,通過乙個例子講述了如何使用簡單工廠模式。同時也留下了乙個問題,那就是簡單工廠模式破壞了開放-封閉原則。那麼本文將介紹另外一種設計模式——工廠方法模式。主要介紹其概念、用途、實現方式、以及優缺點等。

工廠方法模式(factory method pattern)又稱為工廠模式,也叫虛擬構造器(virtual constructor)模式或者多型工廠(polymorphic factory)模式,它屬於類建立型模式。

工廠方法模式是一種實現了「工廠」概念的物件導向設計模式。就像其他建立型模式一樣,它也是處理在不指定物件具體型別的情況下建立物件的問題。

工廠方法模式的實質是「定義乙個建立物件的介面,但讓實現這個介面的類來決定例項化哪個類。工廠方法讓類的例項化推遲到子類中進行。」

工廠方法模式和簡單工廠模式雖然都是通過工廠來建立物件,他們之間最大的不同是——工廠方法模式在設計上完全完全符合「開閉原則」。在以下情況下可以使用工廠方法模式:

乙個類不知道它所需要的物件的類:在工廠方法模式中,客戶端不需要知道具體產品類的類名,只需要知道所對應的工廠即可,具體的產品物件由具體工廠類建立;客戶端需要知道建立具體產品的工廠類。

乙個類通過其子類來指定建立哪個物件:在工廠方法模式中,對於抽象工廠類只需要提供乙個建立產品的介面,而由其子類來確定具體要建立的物件,利用物件導向的多型性和黎克特制代換原則,在程式執行時,子類物件將覆蓋父類物件,從而使得系統更容易擴充套件。

將建立物件的任務委託給多個工廠子類中的某乙個,客戶端在使用時可以無須關心是哪乙個工廠子類建立產品子類,需要時再動態指定,可將具體工廠類的類名儲存在配置檔案或資料庫中。

工廠方法模式包含如下角色:

product:抽象產品(operation

concreteproduct:具體產品(operationadd)

factory:抽象工廠(ifactory)

concretefactory:具體工廠(addfactory)

這裡還用計算器的例子。在保持operationoperationaddoperationdivoperationsuboperationmul等幾個方法不變的情況下,修改簡單工廠模式中的工廠類(operationfactory)。替代原有的那個」萬能」的大工廠類,這裡使用工廠方法來代替:

//工廠介面

public

inte***ce

ifactory

//加法類工廠

public

class

addfactory

implements

ifactory

}//除法類工廠

public

class

divfactory

implements

ifactory

}//除法類工廠

public

class

mulfactory

implements

ifactory

}//減法類工廠

public

class

subfactory

implements

ifactory

}

這樣,在客戶端中想要執行加法運算時,需要以下方式:

public

class

main

}

到這裡,乙個工廠方法模式就已經寫好了。

從**量上看,這種工廠方法模式比簡單工廠方法模式更加複雜。針對不同的操作(operation)類都有對應的工廠。很多人會有以下疑問:

貌似工廠方法模式比簡單工廠模式要複雜的多?

工廠方法模式和我自己建立物件沒什麼區別?為什麼要多搞出一些工廠來?

下面就針對以上兩個問題來深入理解一下工廠方法模式。

封裝物件的建立過程

在工廠方法模式中,工廠方法用來建立客戶所需要的產品,同時還向客戶隱藏了哪種具體產品類將被例項化這一細節,使用者只需要關心所需產品對應的工廠,無須關心建立細節,甚至無須知道具體產品類的類名。基於工廠角色和產品角色的多型性設計是工廠方法模式的關鍵。它能夠使工廠可以自主確定建立何種產品物件,而如何建立這個物件的細節則完全封裝在具體工廠內部。工廠方法模式之所以又被稱為多型工廠模式,是因為所有的具體工廠類都具有同一抽象父類。

符合『開放-封閉原則』

主要目的是為了解耦。在系統中加入新產品時,無須修改抽象工廠和抽象產品提供的介面,無須修改客戶端,也無須修改其他的具體工廠和具體產品,而只要新增乙個具體工廠和具體產品就可以了。這樣,系統的可擴充套件性也就變得非常好,完全符合「開閉原則」。

以上就是工廠方法模式的優點。但是,工廠模式也有一些不盡如人意的地方:

在新增新產品時,需要編寫新的具體產品類,而且還要提供與之對應的具體工廠類,系統中類的個數將成對增加,在一定程度上增加了系統的複雜度,有更多的類需要編譯和執行,會給系統帶來一些額外的開銷。

由於考慮到系統的可擴充套件性,需要引入抽象層,在客戶端**中均使用抽象層進行定義,增加了系統的抽象性和理解難度,且在實現時可能需要用到dom、反射等技術,增加了系統的實現難度。

工廠模式克服了簡單工廠模式違背開放-封閉原則的缺點,又保持了封裝物件建立過程的優點。

他們都是集中封裝了物件的建立,使得要更換物件時,不需要做大的改動就可實現,降低了客戶端與產品物件的耦合。

工廠方法模式是簡單工廠模式的進一步抽象和推廣。

由於使用了物件導向的多型性,工廠方法模式保持了簡單工廠模式的優點,而且克服了它的缺點。

在工廠方法模式中,核心的工廠類不再負責所有產品的建立,而是將具體建立工作交給子類去做。這個核心類僅僅負責給出具體工廠必須實現的介面,而不負責產品類被例項化這種細節,這使得工廠方法模式可以允許系統在不修改工廠角色的情況下引進新產品。

工廠方法模式的主要優點是增加新的產品類時無須修改現有系統,並封裝了產品物件的建立細節,系統具有良好的靈活性和可擴充套件性;其缺點在於增加新產品的同時需要增加新的工廠,導致系統類的個數成對增加,在一定程度上增加了系統的複雜性。

文中所有**見github

設計模式(三) 工廠方法模式

工廠模式一般分為三種 簡單工廠,工廠方法,抽象工廠 簡單工廠 簡單工廠模式又叫靜態工廠方法模式,是通過專門定義乙個類負責建立其他類的例項,被建立的例項通常都具有共同的父類。簡單工廠將物件的建立過程進行了封裝,使用者不需要知道具體的建立過程,只需要呼叫工廠類獲取物件即可。工廠類的寫法是通過switch...

設計模式(三) 工廠方法模式

工廠方法模式是我們前面提到的簡單工廠模式的延伸,他是gof23中的建立型模式,解決的仍然是產品物件建立相關問題,也是我們比較常用的一種設計模式。工廠方式法模式 factory method 定義了乙個用於建立物件的介面,讓子類決定例項化哪乙個類。工廠方法使乙個類的例項化延遲到子類。型別是建立型模式。...

設計模式之(三) 工廠方法模式

女媧補天的故事大家都聽過吧,這個故事是說,女媧在補了天後,下到凡間一看,哇塞,風景太優美了,天空是湛 藍的,水是清澈的,空氣是清新的,太美麗了,然後就待時間長了就有點寂寞了,沒有動物,這些看的到 都是靜態的東西呀,怎麼辦?別忘了是神仙呀,沒有辦不到的事情,於是女媧就架起了八卦爐 技術術語 建立工廠 ...