Java JDK DOM解析器：为什么是工厂？

我目前正在使用JDK的标准DOM解析器进行XML解析

然而，我认为这将是一个很好的时间来理解工厂模式的意义。我以前尝试过寻找Factory实用程序的示例，许多解释都试图使用以下示例：

“如果用户将‘Dog’作为字符串输入，我们可以使用AnimalFactory来识别‘Dog’并实例化相应的对象，这在我们不知道运行时需要什么时非常有用。”

不过，这些示例并没有真正让我明白这一点（可能是因为我忽略了一些东西），我觉得理解为什么在JDK的标准DOM解析器中实现Factory将真正帮助我（希望还有其他人）解决这个问题。这就是：

我已经了解到，读取XML文档需要实例化DocumentBuilder对象，这只能通过从DocumentBuilderFactory对象检索来实现，如下所示：

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

现在，我们可以像这样向其传递文件对象：

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

但是，为什么工艺值得采用工厂模式呢？为什么上述方法比DocumentBuilder拥有自己的显式构造函数并以相同的方式传递文件要好

在这种情况下，是否只是为具有类似目的的对象组织构造函数的问题

---

提前感谢。

DocumentBuilderFactory.newInstance（）将返回以下两种实现之一：

“javax.xml.parsers.DocumentBuilderFactory”

如果不存在的话

“com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl”

我不是百分之百确定——但在这个特定的例子中——它看起来想为您提供一个更新的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（），则只需在一个位置更新创建代码

该模式通常用于创建具有相同契约（接口）的对象，因此它通常有助于多态性

如果有不清楚的地方，请告诉我，我会更新我的答案

---

下面是我最喜欢的设计模式书中关于它的一章：

在JAXP接口的情况下，工厂模式的使用是为了使应用程序能够在不被“锁定”到JAXP接口的特定实现的情况下编写；相反，它允许在运行时根据外部配置（例如类路径上的内容和系统属性值）选择实现库

这一方针取得了好坏参半的成功。虽然它确实可以很容易地从一个实现切换到另一个实现（例如，从Xalan切换到Saxon），但它也可以让应用程序使用从未测试过的XML解析器或XSLT引擎执行，如果应用程序依赖于特定应用程序的特性，那么如果运行时配置不正确，它将以不可预测的方式失败。例如，很常见的情况是，仅仅因为Saxon位于类路径上，就可以看到使用Xalan编写和测试的应用程序失败