デザインパターンのファクトリモデルの解釈

ファクトリパターンの定義:オブジェクトを作成するためのファクトリインターフェイスを定義し、オブジェクトの実際の作成を特定のサブファクトリクラスに延期します。

                             これは、作成モデルに必要な「作成と使用の分離」の機能を満たしています。

実際のビジネスシナリオで分割すると、ファクトリパターンには、単純ファクトリパターン、ファクトリメソッドパターン、および抽象ファクトリパターンの3つの異なる実装方法があります。

単純なファクトリパターン:特定のファクトリクラスは、複数の異なる製品オブジェクトを生成できます。単純なファクトリパターンは、23のデザインパターンに属していません。

                         単純なファクトリパターンでインスタンスを作成する方法は通常静的メソッドであるため、単純なファクトリパターンは静的ファクトリメソッドパターンとも呼ばれます。

単純なファクトリパターンの実現:

//产品接口
public interface Tea {
    void show();
}

//红茶
public class RedTea implements Tea{
     @Override
     public void show() {
         System.out.println("制作红茶!!!");
     }
}

//绿茶
public class GreenTea implements Tea{
    @Override
    public void show() {
        System.out.println("制作绿茶!!!");
    }
}

//工厂类
public class SimpleFactory {
    public static Tea makeTea(int type){
        if(type == 1){
            return new RedTea();
        }else if(type ==2){
            return new GreenTea();
        }else{
            System.out.println("制作失败!!!");
            return null;
        }
    }
}

//测试类
public class Test {
    public static void main(String[] args) {
        Tea tea = SimpleFactory.makeTea(1);
        tea.show();
    }
}

単純な工場モデルの構造図:

単純なファクトリパターンの利点:1。ファクトリクラスには、どの製品のインスタンスをいつ作成するかを決定するために必要な論理的判断が含まれています。

                                    2.クライアントは、作成された特定の製品のクラス名を知る必要はなく、パラメーターのみを知る必要があります。

                                    3.クライアントコードを変更せずに、新しい特定の製品カテゴリを置き換えて追加するための構成ファイルを導入することもできます。

単純なファクトリパターンのデメリット:1。単純なファクトリパターンのファクトリタイプは単一であり、すべての製品の作成に責任があり、責任が重すぎます。

                                     2.ファクトリコードは非常に肥大化し、高集約の原則に違反します。

                                    3.単純なファクトリモデルを使用すると、システム内のクラスの数が増え、システムを理解するのが複雑になり、困難になります。

                                    4.システムの拡張が難しい。新製品を追加するには、ファクトリロジックを変更する必要があります。製品の種類が多い場合、ロジックが複雑すぎる可能性があります。

                                    5.単純なファクトリモデルは静的ファクトリメソッドを使用します。これにより、ファクトリの役割が継承に基づいて階層構造を形成するのを防ぎます。

ファクトリメソッドパターン:オブジェクトを作成するためのインターフェイスを定義し、このインターフェイスを実装するクラスに作成するオブジェクトを決定させます。

                         ファクトリメソッドは、元のコードを変更せずに新製品を導入し、オープンとクローズの原則を満たすことができる単純なファクトリをさらに抽象化したものです。

ファクトリメソッドパターンの実現:

//产品接口
public interface Tea {
    void make();
}

//红茶
public class RedTea implements Tea{
    @Override
    public void make() {
        System.out.println("制作红茶!!!");
    }
}

//绿茶
public class GreenTea implements Tea{
    @Override
    public void make() {
        System.out.println("制作绿茶!!!");
    }
}

//工厂接口
public interface Factory {
    Tea create();
}

//红茶工厂
public class RedTeaFactory implements Factory{
    @Override
    public Tea create() {
        return new RedTea();
    }
}

//绿茶工厂
public class GreenTeaFactory implements Factory{
    @Override
    public Tea create() {
        return new GreenTea();
    }
}

//测试类
public class FactoryMethodTest {
    public static void main(String[] args) {
        Factory redTeaFactory = new RedTeaFactory();
        Tea redTea = redTeaFactory.create();
        redTea.make();

        Factory greenTeaFactory = new GreenTeaFactory();
        Tea greenTea = greenTeaFactory.create();
        greenTea.make();
    }
}

ファクトリメソッドパターン構造図:

ファクトリメソッドパターンの利点:1。ユーザーは、特定のファクトリの名前を知っているだけで目的の製品を取得でき、製品の特定の作成プロセスを知る必要はありません。

                                    2.柔軟性の向上。新製品の作成には、対応するファクトリクラスをもう1つ作成するだけで済みます。

                                    3.典型的なデカップリングフレームワーク。高レベルのモジュールは、製品の抽象クラスを知っているだけでよく、他の実装クラスを気にする必要はありません。

ファクトリメソッドパターンのデメリット:1。クラスの数が多すぎると、複雑さが増します。

                                    2.システムの抽象化と理解の難しさが増しました。

                                    3.抽象製品は1つの製品しか生成できません。

抽象ファクトリパターン:アクセスクラスの関連オブジェクトまたは相互依存オブジェクトのグループを作成するためのインターフェイスを提供します。アクセスクラスは、オブジェクトの特定のクラスを指定せずに取得できます。

                         同じ製品ファミリの製品。抽象ファクトリパターンは、ファクトリメソッドパターンのアップグレードバージョンです。ファクトリメソッドパターンは、1つのレベルの製品のみを生成します。

                         抽象ファクトリモデルは、複数のレベルの製品を生成できます。

製品ファミリ:同じ特定の工場で製造されたさまざまなレベルの製品のグループは、製品ファミリと呼ばれます。

製品グレード:同じタイプの製品は製品グレードと呼ばれます。

抽象ファクトリパターンの実装:

//茶接口
public interface Tea {
    void make();
}

//红茶
public class RedTea implements Tea{
    @Override
    public void make() {
        System.out.println("制作红茶!!!");
    }
}

//绿茶
public class GreenTea implements Tea{
    @Override
    public void make() {
        System.out.println("制作绿茶!!!");
    }
}

//奶接口
public interface Milk {
    void make();
}

//牛奶
public class NiuNai implements Milk{
    @Override
    public void make() {
        System.out.println("制作牛奶!!!");
    }
}

//羊奶
public class YangNai implements Milk{
    @Override
    public void make() {
        System.out.println("制作羊奶!!!");
    }
}

//工厂接口
public interface Factory {
    Tea create();

    Milk produce();
}

//工厂1
public class Factory1 implements Factory{
    @Override
    public Tea create() {
        return new RedTea();
    }

    @Override
    public Milk produce() {
        return new NiuNai();
    }
}

//工厂2
public class Factory2 implements Factory{
    @Override
    public Tea create() {
        return new GreenTea();
    }

    @Override
    public Milk produce() {
        return new YangNai();
    }
}

//测试类
public class AbstractFactoryTest {
    public static void main(String[] args) {
        Factory factory = new Factory1();
        Tea tea = factory.create();
        Milk milk = factory.produce();
        tea.make();
        milk.make();
    }
}

抽象ファクトリパターンの構造図:

抽象ファクトリモデルの利点:1。ユーザーは、製品の特定の作成プロセスを知らなくても、特定のファクトリの名前を知っているだけで目的の製品を取得できます。

                                    2.典型的なデカップリングフレームワーク。高レベルのモジュールは、製品の抽象クラスを知っているだけでよく、他の実装クラスを気にする必要はありません。

                                    3.製品ファミリ内の関連するマルチレベル製品は、クラス内で共同で管理できます。

                                    4.製品ファミリが必要な場合、抽象ファクトリは、クライアントが1つのファクトリのみを使用するようにすることができます。

                                    5.プログラムのスケーラビリティが強化されます。新しい製品ファミリが追加された場合、開始と終了の原則を満たすために元のコードを変更する必要はありません。

抽象ファクトリパターンのデメリット:1。新製品を製品ファミリに追加する必要がある場合は、すべてのファクトリクラスを変更する必要があります。

                                    2.システムの抽象化と理解の難しさが増しました。

おすすめ

転載: blog.csdn.net/wmqyp1415/article/details/114939681