JDK DOM解析器：爲什麼工廠？

我目前正在使用JDK的標準DOM解析器進行XML解析。JDK DOM解析器：爲什麼工廠？

但是，我認爲這將是瞭解Factory模式的重點所在。我嘗試過之前找到Factory的實用程序的示例，並且許多解釋嘗試使用如下示例：

「如果用戶輸入'Dog'作爲字符串，我們可以使用AnimalFactory識別'Dog'並實例化相應的對象，如果我們不知道我們在運行時需要什麼，這很有用。「（這可能是由於我忽略了一些東西），我覺得理解爲什麼Factory在JDK的標準DOM解析器中實現會真的幫助我（並希望其他人）出來。所以在這裏，它是：

我讀過，讀取XML文檔中需要的DocumentBuilder對象 - 的實例只能通過從的DocumentBuilderFactory對象檢索像這樣：

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); 
DocumentBuilder builder = factory.newDocumentBuilder();

現在讓我們通過一個文件對象像這樣：

File myFile = Paths.get(fooPath).toFile(); 
builder.parse(myFile);

但是，爲什麼過程值得工廠模式？爲什麼上述方法比DocumentBuilder具有自己的顯式構造函數並以相同方式傳遞文件更好？

在這種情況下，這是否只是爲類似目的的對象組織構造函數的問題？

在此先感謝。

來源

2016-08-29 Sam S.

的DocumentBuilderFactory.newInstance（）將返回一個有兩個實現方式之一：

一個「javax.xml.parsers.DocumentBuilderFactory中的」

，或者如果不存在

a「com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl」。

我不是100％確定的 - 但在這個特定情況下 - 它看起來像它想給你一個更新的DocumentBuilderFactory實現（與JRE一起）。如果它不在那裏，你會得到舊的。

工廠模式的力量是它會返回一些可以用於編碼器（你）擔心實現的東西。如果它來自java.xml.parsers包或舊的com.sun.org.apache.xerces.internal.jaxp包，我們知道我們返回的內容可以以相同的方式使用。將來，如果創建新的XML解析器（可能更快），並且他們決定替換javax.xml中的解析器，那麼使用API的編碼器無關緊要 - 它只會「正常工作」。他們將受益於新代碼（如果有的話），或者他們將使用以前的一種實現。

工廠是一種「創作模式」。您可以以相同的方式返回幾種類型的對象，這些對象都可以被程序員執行。

當你在編碼，你會發現自己做的有很多：

MyObject genericObject = null; 

if mySetting.equals("dog") { 
    genericObject = new Dog(); 
} else if { mySetting.equals("cat") { 
    genericObject = new Cat(); 
} 
genericObject.speak();

您將有一個工廠創建正確的對象節省時間。如果你引入一個Snake（），那麼你只需要在一個地方更新創建代碼。

模式通常用於創建具有相同的合同（接口）對象，所以它經常與多態性

幫助，如果事情是不明確讓我知道，我會更新我的答案。

這裏是我最喜歡的設計模式的書就可以了章：Head First Design Patterns

來源

2016-08-29 17:33:32 Allan

在JAXP的情況下，接口使用工廠模式是一種嘗試，以使應用程序，而不被「鎖定在被寫入「到特定的JAXP接口實現;相反，它允許基於外部配置（例如類路徑上的內容和系統屬性的值）在運行時選擇實現庫。

這種方法取得了不同的成功。雖然它使得從一個實現切換到另一個實現（例如Xalan到Saxon）變得非常容易，但它也使得應用程序可以使用從未測試過的XML解析器或XSLT引擎來執行，並且如果應用程序原來依賴於特定應用程序的特性，那麼如果運行時配置不正確，它將以不可預知的方式失敗。例如，看到Xalan編寫和測試的應用程序只是因爲Saxon在類路徑上而失敗並不罕見。

來源

2016-08-29 20:27:38

JDK DOM解析器：爲什麼工廠？

回答

相關問題