以下の抽象的なファクトリデザインパターンを調べていたのは、そのためのUML図です。
私は最善を尽くしたので、このパターンの最良の例を提案してください。しかし、私は習得しやすく、抽象的なファクトリパターンの理解を100%明確にしたいと考えています。アドバイスしてください。
以下の抽象的なファクトリデザインパターンを調べていたのは、そのためのUML図です。
私は最善を尽くしたので、このパターンの最良の例を提案してください。しかし、私は習得しやすく、抽象的なファクトリパターンの理解を100%明確にしたいと考えています。アドバイスしてください。
JDKに組み込まれているDocumentBuilderFactoryクラスを見たことがありますか?これはまさにこれを行い、ターゲットアイテムはDocumentオブジェクトです。
jdkにはDocumentBuilderFactoryクラスがあり、サービスロケーター戦略を使用してDocumentBuilderFactoryクラスの具体的な実装(つまり、xercesまたはその他のパーサー)を検索します。
// Uses service locator approach to find an implementor like xerces
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document document = builder.parse(...);
java.awt.Toolkitは、このもう1つの優れた例です。今回は、JVM実装自体を使用してインスタンスを提供します。
Toolkit toolkit = Toolkit.getDefaultToolkit();
実際の具象クラスは、使用しているOSや、ヘッドレスモードで実行しているかどうかによって異なります。
ファクトリパターンは、オブジェクトの正確なクラスを指定せずにオブジェクトを作成するために使用されるため、これら2つのコンポーネント間の結合が減少することを思い出してください。抽象ファクトリパターンは、すべてのファクトリが実装する必要のあるインターフェイスを定義することにより、デカップリングの量をさらに減らします。したがって、抽象ファクトリの呼び出し元は、ファクトリの実装とオブジェクトの作成方法について何も知りません。呼び出し元は、ファクトリでメソッドを呼び出すと、インターフェイスXの特定のオブジェクトインスタンスが生成されます。
MattのXMLライブラリの例は、実際には良い例です。Document
抽象ファクトリは、解析する実際のドキュメントを表すオブジェクトを作成するXMLパーサーを作成するエンティティです。Document
実際、呼び出し元としてのあなたにとって、オブジェクトを取得する限り、ほとんどの場合、どのパーサーが使用されるかはまったく関係ありません。したがって、単純に抽象ファクトリを使用できます。これにより、有効なパーサーが作成されます(ほとんどの場合;))
Toolkitの例(Mattも言及)は、より教科書のような例です。ユーザー画面にウィンドウを表示したいとします。プラットフォームに依存しない方法でそれを実行したいので、特定の操作を実行できる抽象クラスWindowを定義します。次に、これらのウィンドウを作成するオブジェクトを作成します。たとえば、Win32WindowsFactory
。ただし、コードはプラットフォームに依存しないため、WindowsFactory
メソッドを提供するインターフェイスを定義しますcreateWindow()
。Win32WindowsFactory
を使用するとaがWin32Window
返さLinuxGTKWindowsFactory
れ、aを使用するとaGTKWindow
が返されます。
その最も一般的なユースケースは、依存性注入です。これらのスレッドのいくつかで詳細を見つけることができます 依存性注入とは何ですか?