定義：オブジェクトを作成するためのインターフェイスを定義し、サブクラスにインスタンス化するクラスを決定し、工場メソッドがクラスのインスタンス化をサブクラスに遅らせます。
タイプ：クラスパターンクラス図を作成します：
ファクトリーメソッドパターンコード
Interface iProduct {public void productmethod（）; } class製品実装iproduct {public void productmethod（）{system.out.println（ "product"）; }} interface ifactory {public iProduct createProduct（）; }クラスの工場実装ifactory {public iProduct createProduct（）{return new Product（）; }} public class client {public static void main（string [] args）{ifactory factory = new Factory（）; iProduct生産= Factory.CreateProduct（）; produce.productmethod（）; }}工場モード：
まず、工場モデルについて話す必要があります。工場モードは、抽象化の程度に応じて3つのタイプに分割されます。単純な工場モード（静的工場モードとも呼ばれます）、この記事で説明されている工場メソッドモード、および抽象工場モードです。ファクトリーモードは、プログラミングでよく使用されるモデルです。その主な利点は次のとおりです。
コード構造を明確にし、変更を効果的にカプセル化することができます。プログラミングでは、製品クラスのインスタンス化が複雑で変更可能な場合があります。工場モデルを通じて、製品のインスタンス化がカプセル化されているため、発信者は製品のインスタンス化プロセスを気にする必要はなく、工場に依存して必要な製品を入手するだけです。
発信者から特定の製品カテゴリをブロックします。ファクトリーモードを使用する場合、発信者は製品のインターフェイスのみを気にします。特定の実装に関しては、発信者はまったく注意する必要はありません。特定の実装が変更されたとしても、発信者に影響を与えません。
結合を減らします。通常、製品クラスのインスタンス化は非常に複雑です。多くのクラスに依存する必要があり、これらのクラスは発信者にまったく知られる必要はありません。工場の方法が使用されている場合、私たちがする必要があるのは、製品クラスをインスタンス化してから使用するために発信者に引き渡すことだけです。発信者にとって、製品が依存するクラスは透明です。
ファクトリーメソッドモード：
ファクトリーメソッドパターンのクラス図を通じて、工場メソッドパターンには4つの要素があることがわかります。
工場インターフェイス。ファクトリーインターフェイスは、工場メソッドパターンの中核であり、発信者と直接製品を提供するために使用されます。実際のプログラミングでは、抽象クラスが発信者と対話するインターフェイスとして使用されることがありますが、これは本質的に同じです。
工場の実装。プログラミングでは、工場の実装は、製品をインスタンス化する方法を決定します。これは拡張を実現する方法です。必要な製品の数は、ある特定の工場実装と同じくらい多くの製品です。
製品インターフェイス。製品インターフェイスの主な目的は、製品仕様を定義することであり、すべての製品実装は、製品インターフェイスによって定義された仕様に準拠する必要があります。製品インターフェイスは、発信者が最も気にするものであり、製品インターフェイス定義の利点と短所が発信者のコードの安定性を直接決定します。同様に、製品インターフェイスは抽象クラスに置き換えることもできますが、リヒターの交換原則に違反しないように注意してください。
製品の実装。製品インターフェイスの特定のカテゴリは、クライアントの製品の特定の動作を決定します。
工場メソッドモデルの利点：
1。モジュール間のパッケージングとカップリングを削減します。
2。製品インターフェイスに直面し、製品カテゴリをブロックします。
3.典型的なデカップリングフレームワーク。高レベルのモジュールは、製品の抽象クラスを知る必要があります。
4。ディミテス法、反転への依存の原則、およびリヒター交換の原則を遵守します。
該当するシナリオ：
単純な工場モデル、ファクトリーメソッドモデル、または抽象的な工場モデルであろうと、同様の特性があるため、適用可能なシナリオも同様です。
まず、作成クラスのパターンとして、複雑なオブジェクトが必要な場所でファクトリーメソッドパターンを使用できます。注意すべきことの1つは、複雑なオブジェクトがファクトリーモードの使用に適しているのに対し、単純なオブジェクト、特に新しいオブジェクトは新しいものを介して作成できるオブジェクトは、工場モードを使用する必要はないということです。工場モデルを使用する場合は、システムの複雑さを高めるファクトリークラスを導入する必要があります。
第二に、工場モデルは典型的なデカップリングモードであり、ディミッター法は工場モデルで特に明白です。発信者が自分で製品を組み立てるために依存関係を追加する必要がある場合、彼は工場モデルの使用を検討することができます。オブジェクト間の結合が大幅に減少します。
繰り返しになりますが、工場モデルは抽象アーキテクチャに依存しているため、製品を実装クラスにインスタンス化するタスクを完了し、より良いスケーラビリティを備えています。言い換えれば、システムをよりスケーラブルにする必要がある場合、工場モデルを考慮し、異なる実装工場で異なる製品を組み立てることができます。
典型的なアプリケーション
工場モデルの利点を説明するために、車を組み立てるよりも適切な例がないかもしれません。シナリオは次のようなものです。車はエンジン、ホイール、シャーシで構成されており、今では車を組み立てて発信者に引き渡す必要があります。工場モードが使用されていない場合、コードは次のとおりです。
class Engine {public void getStyle（）{system.out.println（ "これは車のエンジンです"）; }} class underpan {public void getStyle（）{system.out.println（ "これは車のシャーシです"）; }} class wheel {public void getStyle（）{system.out.println（ "これは車のタイヤです"）; }} public class client {public static void main（string [] args）{Engine Engine = new Engine（）;アンダーパンアンダーパン= new Underpan（）;ホイールホイール= new Wheel（）; ICAR CAR = NEW CAR（アンダーパン、ホイール、エンジン）; car.show（）; }}車を組み立てるためには、発信者がエンジン、シャーシ、タイヤをインスタンス化する必要があり、これらの車のコンポーネントは発信者とは無関係であり、ディミット法に深刻な違反であり、カップリングが高すぎることがわかります。そして、それは拡張するのに非常に不利です。さらに、この例では、エンジン、シャーシ、タイヤが比較的特異的です。実際のアプリケーションでは、これらの製品のコンポーネントが抽象的である可能性があり、発信者は製品を組み立てる方法を知りません。工場の方法を使用すると、アーキテクチャ全体がはるかに明確に見えます。
インターフェイスifactory {public icar createcar（）; }クラスの工場実装ifactory {public icar createcar（）{Engine Engine = new Engine（）;アンダーパンアンダーパン= new Underpan（）;ホイールホイール= new Wheel（）; ICAR CAR = NEW CAR（アンダーパン、ホイール、エンジン）;帰りの車; }} public class client {public static void main（string [] args）{ifactory factory = new Factory（）; icar car = factory.createcar（）; car.show（）; }}ファクトリーメソッドを使用した後、コール側のカップリングの程度が大幅に削減されます。工場では、拡張できます。将来、他の車を組み立てたい場合は、別の工場実装を追加するだけです。柔軟性と安定性の両方が大幅に改善されています。
PS：工場メソッドモードとシンプルな工場モード
上記のシンプルな工場モデルは、工場メソッドモデルに非常に似ています。 Factory Methodクラスのコアは抽象的な工場クラスであり、単純な工場モデルは具体的なクラスにコアを配置します。ファクトリーメソッドモデルと単純な工場モデルの違いはそれほど明白ではありません。