從DRP架構進行簡單工廠代替抽象工廠的SWOT分析

1、簡單工廠 vs 工廠方法vs抽象工廠： [簡單工廠 vs 工廠方法vs抽象工廠]( 2、設計模式總結： [設計模式總結]( 其實在之前剛接觸設計模式的時候，對於三工廠模式理解的並不是特別到位，尤其是為什麼在一些時候我們會用簡單工廠來代替抽象工廠，始終不是特別的理解。畢竟簡單工廠並沒有列入gof的23個設計模式之中啊。那麼今天，就關於drp這個專案中的架構演化來分析一下簡單工廠取代抽象工廠的前因後果吧！

在drp中初衷為了解決便於適應多種資料庫格式編碼，採用了抽象工廠架構模式。那麼具體如何使用的，且看一張圖。

說明：此圖並未將所有的系列都畫出來。只是為了說明冗餘類的龐大。這裡只是畫出了dao層，其實我們還需要在邏輯層b建立抽象工廠，以便於讓servlet來方便建立對應的業務邏輯層的例項。從圖中我們可以看出，為了使用抽象工廠來適應多資料庫的情況，僅物料乙個類別就必須多加三個類，那如果乙個專案中的業務類達到上百個之多的話，那得增加多少個類啊，還有如果我們還想再邏輯層再解耦的話，如果再使用抽象工廠，這樣的話，出現的冗餘也太多了，是不是就應該考慮其他的模式了呢？

那麼為了減少冗餘，我們用簡單工廠來代替了抽象工廠，看一下類圖：

看上面這張類圖，看著似乎類也並沒有少了多少啊，再仔細看看，其實這張類圖早已包含了業務邏輯b層和資料訪問d層兩層的實現類和工廠的關係了。在這個圖中我們發現為建立類而多出來的只有beanfacoty這乙個工廠類。在這個工廠類中，為了進一步解耦，我們使用了讀取配置檔案的方法，來隨時變更適合我們的實現類，這樣就不用害怕資料庫更換了。這樣相比抽象工廠就簡單多了吧。

光說不練假把式，我們來看一下具體的**吧！配置檔案：bean-sys.xml

<?xml version="1.0" encoding="utf-8"?>
id="com.bjpowernode.drp.basedata.manager.itemmanager"
class="com.bjpowernode.drp.basedata.manager.itemmanagerimpl"/>
service-class>
id="com.bjpowernode.drp.basedata.dao.itemdao"
class="com.bjpowernode.drp.basedata.dao.itemdao4oracleimpl" />
dao-class>
beans>

beanfactory對配置檔案的讀取：

public
class
beanfactory  catch (documentexception e) 
}public
static beanfactory getinstance()
/*** 根據產品編號取得service系列產品，對應業務邏輯層
*@param beanid
*@return
*/public
synchronized object getserviceobject(class c)
//如果不存在，則建立乙個
//  //代表以bean路徑結尾的所有元素，用「//」 表示所有路徑以"//"後指定的子路徑結尾的元素 
element beanelt=(element) doc.selectsinglenode("//service[@id=\""+c.getname()+"\"]");
/*string classname=beanelt.gettexttrim();*/
string classname=beanelt.attributevalue("class");
object service=null;
try  catch (exception e)  
return service;
}/**
* 根據產品編號取得dao系列產品
*@param beanid
*@return
*/public
synchronized object getdaoobject(class c)
//如果不存在，則建立乙個
//  //代表以bean路徑結尾的所有元素，用「//」 表示所有路徑以"//"後指定的子路徑結尾的元素 
element beanelt=(element) doc.selectsinglenode("//dao[@id=\""+c.getname()+"\"]");
/*string classname=beanelt.gettexttrim();*/
string classname=beanelt.attributevalue("class");
object dao=null;
try  catch (exception e)  
return dao;}}

當然，這裡為了防止在呼叫時容易造成的書寫錯誤，採用了類的全名來作為id值，這樣我們讀取的時候就可以直接按類名讀取，如果一旦拼寫出錯，編譯是不能通過的。所以大大方便了程式的編寫。程式的呼叫：

itemmanager=(itemmanager)beanfactory.getinstance().getserviceobject(itemmanager.class);

怎麼樣，是不是簡單了許多呢？雖然簡單工廠並沒有滿足ocp原則，但是通過上面的比較，我們發現，如果採用簡單工廠，在簡單工廠中只需要兩個方法就可以實現b和d兩層類的例項建立，而採用抽象工廠卻要徒勞的多增加很多類，這樣比較下來，還是採用簡單工廠更加適合。這裡把設計模式沒有最好只有更好的特點體現的淋漓盡致了吧！

從DRP架構進行簡單工廠代替抽象工廠的SWOT分析

簡單工廠工廠抽象工廠的區別

簡單工廠，工廠，抽象工廠的區別

簡單工廠工廠抽象工廠的區別

從DRP架構進行簡單工廠代替抽象工廠的SWOT分析

簡單工廠 工廠 抽象工廠的區別

簡單工廠，工廠，抽象工廠的區別

簡單工廠 工廠 抽象工廠的區別

相關推薦

簡單工廠工廠抽象工廠的區別

簡單工廠工廠抽象工廠的區別