Javaデザインパターンのファクトリメソッドパターン（Factory Method Pattern）

コンセプト

ファクトリメソッドパターン (ファクトリメソッドパターン) は、ファクトリパターンとも呼ばれ、仮想コンストラクター (仮想コンストラクター) パターンまたはポリモーフィックファクトリ (ポリモーフィックファクトリ) パターンとも呼ばれ、クラス作成パターンに属します。

ファクトリメソッドパターンは、「ファクトリ」の概念を実装するオブジェクト指向の設計パターンです。他の作成パターンと同様に、具体的なタイプを指定せずにオブジェクトを作成することも扱います。

ファクトリメソッドパターンの本質は、「オブジェクトを作成するためのインターフェイスを定義しますが、どのクラスをインスタンス化するかは、このインターフェイスを実装するクラスに決定させます。ファクトリメソッドは、クラスのインスタンス化をサブクラスに任せます。」です。

使用

ファクトリメソッドパターンと [単純なファクトリパターン][2] はどちらもファクトリを使用してオブジェクトを作成しますが、それらの最大の違いは、ファクトリメソッドパターンが「[開閉原則][3]」に完全に準拠するように設計されていることです。

ファクトリメソッドパターンは、次の場合に使用できます。

クラスは、必要なオブジェクトのクラスを知りません。ファクトリメソッドパターンでは、クライアントは特定の製品クラスのクラス名を知る必要はありませんが、対応するファクトリだけを知っていればよく、特定の製品オブジェクトは特定のファクトリクラスによって作成される; クライアントは、具体的な製品を作成するためにファクトリクラスを知る必要があります。

クラスは、そのサブクラスを通じてどのオブジェクトを作成するかを指定します。ファクトリメソッドパターンでは、抽象ファクトリクラスは製品を作成するためのインターフェイスを提供するだけでよく、そのサブクラスは、オブジェクト指向ポリモーフィズムを使用して、作成される特定のオブジェクトを決定します。置換原理 [3] により、プログラム実行時にサブクラスオブジェクトが親クラスオブジェクトをカバーするため、システムの拡張が容易になります。

オブジェクト作成のタスクを複数のファクトリサブクラスのいずれかに委任します。これを使用する場合、クライアントはどのファクトリサブクラスがプロダクトサブクラスを作成するかを気にする必要はありません。必要に応じて動的に指定できます。特定のファクトリクラスのクラス名設定ファイルまたはデータベースに保存できます。

実現方法

ファクトリメソッドパターンには次の役割が含まれます。

製品: 抽象製品 ( Operation)

ConcreteProduct: コンクリート製品 ( OperationAdd)

ファクトリ: 抽象ファクトリ ( IFactory)

ConcreteFactory: コンクリート工場 ( AddFactory)

[ QQ20160412-0 ][4]

こちらも電卓を使った例です。Operation、、、などの複数のメソッドを変更しない場合は、単純なファクトリパターン内のファクトリクラス()を変更しOperationAddます。元の「ユニバーサル」ビッグファクトリクラスの代わりに、ファクトリメソッドがここにあります。OperationDivOperationSubOperationMulOperationFactory

//工厂接口
public interface IFactory {
    Operation CreateOption();
}

//加法类工厂
public class AddFactory implements IFactory {

    public Operation CreateOption() {
        return new OperationAdd();
    }
}

//除法类工厂
public class DivFactory implements IFactory {

    public Operation CreateOption() {
        return new OperationDiv();
    }
}

//除法类工厂
public class MulFactory implements IFactory {

    public Operation CreateOption() {
        return new OperationMul();
    }
}

//减法类工厂
public class SubFactory implements IFactory {

    public Operation CreateOption() {
        return new OperationSub();
    }
}

このように、クライアントで追加操作を実行したい場合は、次のメソッドが必要です。

public class Main {

    public static void main(String[] args) {
        IFactory factory = new AddFactory();
        Operation operationAdd =  factory.CreateOption();
        operationAdd.setValue1(10);
        operationAdd.setValue2(5);
        System.out.println(operationAdd.getResult());
    }
}

この時点で、ファクトリメソッドパターンが書き込まれました。

コードサイズの観点から見ると、このファクトリメソッドパターンは単純なファクトリメソッドパターンよりも複雑です。さまざまな操作クラスに対応するファクトリがあります。多くの人が次のような疑問を抱いています。

ファクトリメソッドパターンは単純なファクトリパターンよりも複雑なようですか？

ファクトリメソッドパターンは自分でオブジェクトを作成するのと変わりませんか? なぜさらに多くの工場を建設する必要があるのでしょうか?

上記の 2 つの質問に対するファクトリメソッドのパターンを詳しく見てみましょう。

ファクトリメソッドパターンの長所と短所

オブジェクトの作成になぜファクトリーを使用するのでしょうか?

オブジェクト作成プロセスをカプセル化する

ファクトリメソッドパターンでは、ファクトリメソッドは顧客が必要とする製品を作成するために使用されますが、同時にどの特定の製品クラスがインスタンス化されるかについての詳細は顧客から隠蔽されます。ユーザーはファクトリが対応することだけを気にする必要があります。必要な製品にアクセスできるため、特定の製品クラスのクラス名さえわからなくても詳細を作成する必要がありません。

ファクトリの役割と製品の役割に基づいたポリモーフィックな設計が、ファクトリメソッドパターンの鍵となります。**これにより、工場はどの製品オブジェクトを作成するかを独自に決定でき、このオブジェクトの作成方法の詳細は特定の工場内に完全にカプセル化されます。**ファクトリメソッドパターンがポリモーフィックファクトリパターンとも呼ばれる理由は、すべての具象ファクトリクラスが同じ抽象親クラスを持つためです。

各オブジェクトに個別のファクトリーがあるのはなぜですか?

「[オープン・クローズの原則][5]」を遵守する

主な目的はデカップリングです。システムに新しいプロダクトを追加する場合、抽象ファクトリと抽象プロダクト、クライアント、その他の特定のファクトリと特定のプロダクトが提供するインターフェイスを変更する必要はなく、特定のファクトリと特定のプロダクトを追加するだけで済みます。このようにして、システムの拡張性は非常に良好になり、「[開閉原則][3]」に完全に準拠します。

以上がファクトリーメソッドパターンのメリットです。ただし、ファクトリーパターンにもいくつか不十分な点があります。

新しいプロダクトを追加する場合、新しい特定のプロダクトクラスを作成し、対応する特定のファクトリクラスを提供する必要があり、システム内のクラスの数がペアで増加するため、システムの複雑さがある程度増加します。クラスをコンパイルして実行する必要があるため、システムに追加のオーバーヘッドが発生します。

システムのスケーラビリティを考慮すると、抽象化層を導入する必要があります。これは、抽象化層を使用してクライアントコードで定義されます。これにより、システムの抽象化と理解が難しくなり、DOM、リフレクション、および DOM の使用が必要になる場合があります。実装中に他のテクノロジーが使用されるため、システム実装の難易度が増加します。

ファクトリーメソッドとシンプルファクトリーの違い

ファクトリパターンは、単純なファクトリパターンが [オープン-クローズ原則][3] に違反するという欠点を克服し、オブジェクト作成プロセスをカプセル化する利点を維持します。

これらはすべて、オブジェクトの作成を一元的にカプセル化しているため、オブジェクトを置き換える必要がある場合に大きな変更を加えることなく実現でき、クライアントと製品オブジェクトの間の結合が軽減されます。

要約する

ファクトリメソッドパターンは、単純なファクトリパターンをさらに抽象化し、推進したものです。

オブジェクト指向ポリモーフィズムの使用により、ファクトリメソッドパターンは単純なファクトリパターンの利点を維持し、その欠点を克服します。

ファクトリメソッドパターンでは、コアファクトリクラスはすべての製品の作成を担当しなくなり、特定の作成作業はサブクラスに引き渡されます。このコアクラスは、特定のファクトリが実装する必要があるインターフェイスを提供することのみを担当し、インスタンス化される製品クラスの詳細には責任を負いません。これにより、ファクトリメソッドパターンにより、システムはファクトリの役割を変更せずに新しい製品を導入できるようになります。

ファクトリメソッドパターンの主な利点は、新しい製品カテゴリを追加するときに既存のシステムを変更する必要がなく、製品オブジェクトの作成の詳細がカプセル化されることです。このシステムには優れた柔軟性と拡張性があります。欠点は、次のことを行う必要があることです。新しい製品を追加しながら、工場ではシステムクラスの数がペアで増加し、システムの複雑さがある程度増加しました。