跟JBPM學習設計模式之簡單工廠模式

跟jbpm學習設計模式之簡單工廠模式

模式簡介

簡單工廠模式是類的建立模式，其專門負責將大量擁有共同介面或者基類的產品類進行例項化。簡單工廠模式由工廠類執行時根據傳入的引數動態的決定需要例項化的類，這樣客戶只需要了解產品的基類，解除客戶對具體產品類的依賴。簡單工廠模式的結構如下圖所示

圖 1. 簡單工廠模式結構圖

從圖中可以看出，簡單工廠模式主要涉及一下三種結構角色

1. 工廠類，其有客戶端直接呼叫，並根據具體的業務邏輯要求建立相應的產品物件例項；

2. 產品基類，所有具體的產品類的基類或者介面，封裝所有具體產品共享的行為（和資料）, 客戶需要了解產品基類；

3. 具體的產品類，本模式需要建立的例項的型別；

jbpm中的簡單工廠模式

jbpm中對流程引擎的物件的例項化使用了簡單工廠模式。具體的模式結構圖如下

圖 2. jbpm簡單工廠結構圖

從圖中我們可以看到processengine充當了產品基類的角色，由於流程引擎在jbpm中所處的特殊地位，所以這個介面需要能夠獲取各種服務和業務中需要使用的一些物件例項等。

具體的產品類是processengineimpl和springprocessengine類，jbpm的流程引擎可以使用spring作為承載的環境，預設情況下會使用前者，如果我們需要使用spring，只需要在jbpm.cfg.xml中引入jbpm.tx.spring.cfg.xml即可。

工廠類的角色是由configurationimpl來實現的，其根據配置檔案中是否啟用spring來例項化具體的流程引擎物件。

其實springprocessengine本身也是乙個精簡版的簡單工廠模式，其自己負責例項化自己，其同時擔當了工廠和具體產品的角色。具體的類圖結構如下

圖 3. springprocessengine精簡版簡單工廠設計模式

簡單工廠模式的優劣

該模式的核心是工廠類，其負責必要的邏輯判斷（反射的話可以不需要），決定最終建立哪乙個產品類的例項。客戶是不負責產品類的例項化，而是僅僅使用返回的產品，實現了兩者間的職責分離。

該模式中，工廠類負責所有具體產品類的建立邏輯，所以其就對所有的產品類形成了強烈的依賴，如果產品類很多，可能對工廠類的修改就會影響到整個系統。

當我們擴充套件了新的產品類的時候，需要修改工廠類，違反了開閉原則。