工廠三兄弟之簡單工廠模式(四)
分享一下我老師大神的人工智慧教程!零基礎,通俗易懂!http://blog.csdn.net/jiangjunshow
也歡迎大家轉載本篇文章。分享知識,造福人民,實現我們中華民族偉大復興!
4 方案的改進
Sunny軟體公司開發人員發現在建立具體Chart物件時,每更換一個Chart物件都需要修改客戶端程式碼中靜態工廠方法的引數,客戶端程式碼將要重新編譯,這對於客戶端而言,違反了“開閉原則”,有沒有一種方法能夠在不修改客戶端程式碼的前提下更換具體產品物件呢?答案是肯定的,下面將介紹一種常用的實現方式。
我們可以將靜態工廠方法的引數儲存在XML或properties格式的配置檔案中,如下config.xml所示:
<?xml version="1.0"?><config> <chartType>histogram</chartType></config>
再通過一個工具類XMLUtil來讀取配置檔案中的字串引數,XMLUtil類的程式碼如下所示:
import javax.xml.parsers.*;import org.w3c.dom.*;import org.xml.sax.SAXException;import java.io.*;public class XMLUtil { //該方法用於從XML配置檔案中提取圖表型別,並返回型別名 public static String getChartType() { try { //建立文件物件 DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance(); DocumentBuilder builder = dFactory.newDocumentBuilder(); Document doc; doc = builder.parse(new File("config.xml")); //獲取包含圖表型別的文字節點 NodeList nl = doc.getElementsByTagName("chartType"); Node classNode = nl.item(0).getFirstChild(); String chartType = classNode.getNodeValue().trim(); return chartType; } catch(Exception e) { e.printStackTrace(); return null; } }}
在引入了配置檔案和工具類XMLUtil之後,客戶端程式碼修改如下:
class Client { public static void main(String args[]) { Chart chart; String type = XMLUtil.getChartType(); //讀取配置檔案中的引數 chart = ChartFactory.getChart(type); //建立產品物件 chart.display(); }}
不難發現,在上述客戶端程式碼中不包含任何與具體圖表物件相關的資訊,如果需要更換具體圖表物件,只需修改配置檔案config.xml,無須修改任何原始碼,符合“開閉原則”。
|
5 簡單工廠模式的簡化
有時候,為了簡化簡單工廠模式,我們可以將抽象產品類和工廠類合併,將靜態工廠方法移至抽象產品類中,如圖3所示:
圖3 簡化的簡單工廠模式
在圖3中,客戶端可以通過產品父類的靜態工廠方法,根據引數的不同建立不同型別的產品子類物件,這種做法在JDK等類庫和框架中也廣泛存在。
6 簡單工廠模式總結
簡單工廠模式提供了專門的工廠類用於建立物件,將物件的建立和物件的使用分離開,它作為一種最簡單的工廠模式在軟體開發中得到了較為廣泛的應用。
1. 主要優點
簡單工廠模式的主要優點如下:
(1) 工廠類包含必要的判斷邏輯,可以決定在什麼時候建立哪一個產品類的例項,客戶端可以免除直接建立產品物件的職責,而僅僅“消費”產品,簡單工廠模式實現了物件建立和使用的分離。
(2) 客戶端無須知道所建立的具體產品類的類名,只需要知道具體產品類所對應的引數即可,對於一些複雜的類名,通過簡單工廠模式可以在一定程度減少使用者的記憶量。
(3) 通過引入配置檔案,可以在不修改任何客戶端程式碼的情況下更換和增加新的具體產品類,在一定程度上提高了系統的靈活性。
2. 主要缺點
簡單工廠模式的主要缺點如下:
(1) 由於工廠類集中了所有產品的建立邏輯,職責過重,一旦不能正常工作,整個系統都要受到影響。
(2) 使用簡單工廠模式勢必會增加系統中類的個數(引入了新的工廠類),增加了系統的複雜度和理解難度。
(3) 系統擴充套件困難,一旦新增新產品就不得不修改工廠邏輯,在產品型別較多時,有可能造成工廠邏輯過於複雜,不利於系統的擴充套件和維護。
(4) 簡單工廠模式由於使用了靜態工廠方法,造成工廠角色無法形成基於繼承的等級結構。
3. 適用場景
在以下情況下可以考慮使用簡單工廠模式:
(1) 工廠類負責建立的物件比較少,由於建立的物件較少,不會造成工廠方法中的業務邏輯太過複雜。
(2) 客戶端只知道傳入工廠類的引數,對於如何建立物件並不關心。
|
【作者:劉偉 http://blog.csdn.net/lovelion】