この記事では、Power Node Java Academy によってまとめられたファクトリ メソッドのパターン関連情報を主に紹介します。必要な友人は参照してください。
定義: オブジェクトを作成するためのインターフェイスを定義し、どのクラスをインスタンス化するかをサブクラスに決定させ、ファクトリ メソッドはインスタンス化を延期します。クラスからそのサブクラスへ。
タイプ: クラスパターンの作成
クラス図:
ファクトリメソッドパターンコード
interface IProduct { public void productMethod(); } class Product implements IProduct { public void productMethod() { System.out.println("产品"); } } interface IFactory { public IProduct createProduct(); } class Factory implements IFactory { public IProduct createProduct() { return new Product(); } } public class Client { public static void main(String[] args) { IFactory factory = new Factory(); IProduct prodect = factory.createProduct(); prodect.productMethod(); } }
ファクトリパターン:
まず、必要なのはファクトリーモードについて話します。ファクトリ パターンは、抽象度に応じて、単純ファクトリ パターン (静的ファクトリ パターンとも呼ばれます)、この記事で説明するファクトリ メソッド パターン、および抽象ファクトリ パターンの 3 種類に分類されます。ファクトリパターンはプログラミングでよく使われるパターンです。その主な利点は次のとおりです:
コード構造を明確にし、変更を効果的にカプセル化できます。プログラミングでは、製品クラスのインスタンス化が複雑で変更可能である場合があります。ファクトリ パターンを通じて製品のインスタンス化がカプセル化されるため、呼び出し元は製品のインスタンス化プロセスについてまったく気にする必要がなく、必要なのは製品のインスタンス化プロセスだけです。ご希望の製品を入手するには工場にお任せください。
発信者から特定の製品カテゴリをブロックします。ファクトリ パターンを使用する場合、呼び出し元は製品インターフェイスについてのみ考慮します。具体的な実装については、呼び出し元はまったく考慮する必要はありません。特定の実装が変更された場合でも、呼び出し元には影響しません。
カップリングを減らします。通常、プロダクト クラスのインスタンス化は非常に複雑ですが、ファクトリ メソッドを使用する場合、それらのクラスを呼び出し元に認識させる必要はありません。それを発信者が使用できるようにします。呼び出し元にとって、製品が依存するクラスは透過的です。
ファクトリ メソッド パターン:
ファクトリ メソッド パターンのクラス図から、ファクトリ メソッド パターンには 4 つの要素があることがわかります:
ファクトリ インターフェイス。ファクトリ インターフェイスはファクトリ メソッド パターンの中核であり、呼び出し元と直接対話して製品を提供します。実際のプログラミングでは、呼び出し元と対話するためのインターフェイスとして抽象クラスが使用されることがありますが、本質的には同じです。
工場出荷時の実装。プログラミングでは、ファクトリ実装によって製品をインスタンス化する方法が決まります。これは、拡張を実現する方法であり、必要な製品の数は、必要な特定のファクトリ実装の数によって異なります。
製品インターフェース。製品インターフェイスの主な目的は製品の仕様を定義することであり、すべての製品実装は製品インターフェイスによって定義された仕様に従う必要があります。製品インターフェイスは、呼び出し側が最も懸念するものです。製品インターフェイス定義の品質は、呼び出し側のコードの安定性を直接決定します。同様に、製品インターフェイスも抽象クラスに置き換えることができますが、リスコフ置換原則に違反しないように注意してください。
製品の実装。製品インターフェイスを実装する特定のクラスは、クライアントにおける製品の特定の動作を決定します。
前述の単純なファクトリ パターンは、ファクトリ メソッド パターンと非常に似ています。違いは、単純なファクトリには 3 つの要素しかなく、ファクトリ インターフェイスがなく、製品を取得するメソッドが一般に静的であることです。ファクトリ インターフェイスがないため、ファクトリ実装のスケーラビリティは若干低くなります。ファクトリ メソッド パターンの簡易版と考えることができます。ここでは、単純なファクトリ パターンについて簡単に説明します。
適用可能なシナリオ: 単純なファクトリ モデル、ファクトリ メソッド モデル、または抽象ファクトリ モデルのいずれであっても、それらは類似した特性を持っているため、適用可能なシナリオは類似しています。
代表的なアプリケーション
要说明工厂模式的优点,可能没有比组装汽车更合适的例子了。场景是这样的:汽车由发动机、轮、底盘组成,现在需要组装一辆车交给调用者。假如不使用工厂模式,代码如下:
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(); Underpan underpan = new Underpan(); Wheel wheel = new Wheel(); ICar car = new Car(underpan, wheel, engine); car.show(); } }
可以看到,调用者为了组装汽车还需要另外实例化发动机、底盘和轮胎,而这些汽车的组件是与调用者无关的,严重违反了迪米特法则,耦合度太高。并且非常不利于扩展。另外,本例中发动机、底盘和轮胎还是比较具体的,在实际应用中,可能这些产品的组件也都是抽象的,调用者根本不知道怎样组装产品。假如使用工厂方法的话,整个架构就显得清晰了许多。
interface IFactory { public ICar createCar(); } class Factory implements IFactory { public ICar createCar() { Engine engine = new Engine(); Underpan underpan = new Underpan(); Wheel wheel = new Wheel(); ICar car = new Car(underpan, wheel, engine); return car; } } public class Client { public static void main(String[] args) { IFactory factory = new Factory(); ICar car = factory.createCar(); car.show(); } }
使用工厂方法后,调用端的耦合度大大降低了。并且对于工厂来说,是可以扩展的,以后如果想组装其他的汽车,只需要再增加一个工厂类的实现就可以。无论是灵活性还是稳定性都得到了极大的提高。
以上がJavaのファクトリメソッドパターンの詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。