JDK DOMパーサー：なぜ工場ですか？

Question

私は現在、JDKの標準DOMパーサーを使用してXML解析を行っています。

しかし、私は、これがFactoryパターンのポイントが何であるかを理解する良い時期になると考えました。

"ユーザーが 'Dog'を文字列として入力した場合、AnimalFactoryを使用して 'Dog'を認識して対応するオブジェクトをインスタンス化することができます。この例では、実行時に必要なものがわからない場合に役立ちます。

このような例では、私の見落としが原因で実際​​にはポイントが得られませんし、JDKの標準DOMパーサでFactoryが実装されている理由を理解することができます） でる。だからここにある：

私は、XML文書を読み込むことのみによってようのDocumentBuilderFactoryオブジェクトから取得することができてDocumentBuilderオブジェクト - のインスタンス化が必要であることを読んだ：

今、私たちを可能に

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

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

しかし、なぜプロセスがファクトリパターンにメリットがありますか？ DocumentBuilderが独自の明示的なコンストラクタを持ち、同じ方法でファイルを渡すよりも、上記のアプローチが優れているのはなぜですか？

この場合、同様の目的を持つオブジェクトのコンストラクタを整理するのは単なる質問ですか？

ありがとうございます。

Answer 1

DocumentBuilderFactory.newInstanceは（）は、2つの実装のいずれかの一つを返します：

1. "javax.xml.parsers.DocumentBuilderFactory"

またはそれが

存在しない場合を

2. "com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl"。

私は100％確信していませんが、この特定のケースでは、DocumentBuilderFactory（JREに付属）の新しい実装を提供したいようです。それがない場合は、古いものを取得します。

ファクトリパターンの機能は、実装について心配しているコーダ（あなた）が使用できるものを返します。 java.xml.parsersパッケージまたは古いcom.sun.org.apache.xerces.internal.jaxpパッケージから取得したものは、同じように使用できます。将来、新しいXMLパーサーが作成された場合（おそらく早い場合）、javax.xml内のXMLパーサーを置き換えることに決めた場合、APIを使用するコーダーとは関係なく、「うまくいく」でしょう。彼らは新しいコード（そこにある場合）または以前の実装の1つを使用することで恩恵を受けるでしょう。

工場は「創造的なパターン」です。同じ方法ですべて（プログラマによって）実行可能ないくつかのタイプのオブジェクトを返すことができます。

あなたがコーディングされている場合、あなた自身が多くのをやって見つける：

MyObject genericObject = null; 

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

あなたは工場出荷時には、適切なオブジェクトを作成することによって、時間を節約します。 Snake（）を導入すれば、クリエイティブコードを1か所で更新するだけです。

パターンは、多くの場合、同じ契約（Interface）を持っているので、何かが私を知っていると私は私の答えを更新する明確でない場合、それは多くの場合、ポリモーフィズム

に役立ちますオブジェクトを作成するために使用されます。ここで

は私のお気に入りのデザインパターンの本から、それについての章です：JAXPの場合Head First Design Patterns

Answer 2

は、工場出荷時のパターンの使用は「固定されずに書き込まれるアプリケーションを有効にする試みであるのインタフェース"JAXPインタフェースの特定の実装に、その代わりに、外部の構成（例えば、クラスパスにあるもの、システムプロパティの値など）に基づいて実行時に実装ライブラリを選択することができます。

このアプローチは、成功しました。ある実装から別の実装（XalanからSaxonなど）に切り替えるのは非常に簡単ですが、テストされていないXMLパーサーまたはXSLTエンジンを使用してアプリケーションを実行することもできます。また、アプリケーション特定のアプリケーションの特異性に依存することが判明した場合、実行時設定が正しくないと予測できない方法で失敗します。たとえば、Saxonがクラスパス上にあるため、単にXalanで書かれテストされたアプリケーションが失敗することを念頭におくのは珍しいことではありません。