JAVAデザインパターンの抽象的なファクトリーパターン

単純な ファクトリー パターン と ファクトリー メソッド パターン をすでに紹介しました。ここでは、再び自動車の製造を例として、3 番目のファクトリー パターンである抽象ファクトリー パターンを紹介します。

背景例:

顧客の要求がますます高くなるにつれて、BMW 車にはエアコン、エンジン、その他のアクセサリのさまざまな構成が必要になります。そこで工場は自動車を組み立てるためのエアコンとエンジンの生産を始めました。現時点では、工場にはエアコンとエンジンの 2 つのシリーズの製品があります。 BMW 320 シリーズにはモデル A エアコンとモデル A エンジンが搭載され、BMW 230 シリーズにはモデル B エアコンとモデル B エンジンが搭載されています。

コンセプト:

抽象ファクトリ パターンは、ファクトリ メソッド パターンのアップグレードされたバージョンであり、関連するオブジェクトまたは相互依存するオブジェクトのセットを作成するために使用されます。たとえば、BMW 320 シリーズはエアコン モデル A とエンジン モデル A を使用し、BMW 230 シリーズはエアコン モデル B とエンジン モデル B を使用します。次に、抽象的な工場パターンを使用して、320 シリーズの関連アクセサリを生産する場合、次のようになります。アクセサリーのモデルを指定する必要はありません。車種に応じて、対応するアクセサリーモデルAが自動的に生成されます。

百度百科事典の抽象工場パターンの紹介に基づいて、次の例と組み合わせます:

各抽象製品に複数の特定のサブカテゴリがある場合 (エアコンにはモデル A とモデル B の 2 種類があり、エンジンにもモデル A がある)および B)、ファクトリ ロールはどのサブクラスをインスタンス化するかをどのようにして知るのでしょうか?たとえば、各抽象製品役割には 2 つの特定の製品があります (製品エアコンには、エアコン A とエアコン B の 2 つの特定の製品があります)。抽象ファクトリー パターンは 2 つの特定のファクトリー ロール (BMW 320 シリーズ ファクトリーと BMW 230 シリーズ ファクトリー) を提供します。これらの各特定のファクトリー ロールは、特定の製品ロールのインスタンス化のみを担当します。各具象ファクトリ クラスは、抽象製品の特定のサブクラスのインスタンスを作成することのみを担当します。

Abstract Factory Pattern Code

Product category:

//发动机以及型号    
public interface Engine {    
  
}    
public class EngineA extends Engine{    
    public EngineA(){    
        System.out.println("制造-->EngineA");    
    }    
}    
public class EngineBextends Engine{    
    public EngineB(){    
        System.out.println("制造-->EngineB");    
    }    
}    
  
//空调以及型号    
public interface Aircondition {    
  
}    
public class AirconditionA extends Aircondition{    
    public AirconditionA(){    
        System.out.println("制造-->AirconditionA");    
    }    
}    
public class AirconditionB extends Aircondition{    
    public AirconditionB(){    
        System.out.println("制造-->AirconditionB");    
    }    
}

Create Factory Class:

//创建工厂的接口    
public interface AbstractFactory {    
    //制造发动机  
    public Engine createEngine();  
    //制造空调   
    public Aircondition createAircondition();   
}    
  
  
//为宝马320系列生产配件    
public class FactoryBMW320 implements AbstractFactory{    
        
    @Override    
    public Engine createEngine() {      
        return new EngineA();    
    }    
    @Override    
    public Aircondition createAircondition() {    
        return new AirconditionA();    
    }    
}    
//宝马523系列  
public class FactoryBMW523 implements AbstractFactory {    
    
     @Override    
    public Engine createEngine() {      
        return new EngineB();    
    }    
    @Override    
    public Aircondition createAircondition() {    
        return new AirconditionB();    
    }    
  
  
}

Customer:

public class Customer {    
    public static void main(String[] args){    
        //生产宝马320系列配件  
        FactoryBMW320 factoryBMW320 = new FactoryBMW320();    
        factoryBMW320.createEngine();  
        factoryBMW320.createAircondition();  
            
        //生产宝马523系列配件    
        FactoryBMW523 factoryBMW523 = new FactoryBMW523();    
        factoryBMW320.createEngine();  
        factoryBMW320.createAircondition();  
    }    
}

Abstract Factory PatternとFactory Method Patternの違いについては、ここでは詳しく説明しないと思う。例を何回か読むと理解できますが、製品ファミリーや階層構造などの概念がたくさん出てきますが、話してから理解するのはさらに難しくなります。

Abstract Factory パターンの起源

以下は Abstract Factory パターンの起源からの引用です:

Abstract Factory パターンの起源または最も初期の応用は、さまざまなオペレーティング システムに属するウィンドウ構造を作成することです。たとえば、コマンド ボタン (Button) とテキスト ボックス (Text) は両方ともウィンドウ構造です。UNIX オペレーティング システムのウィンドウ環境と Windows オペレーティング システムのウィンドウ環境では、これら 2 つの構造のローカル実装とそのローカル実装が異なります。詳細は異なります。

どのオペレーティング システムにも、ウィンドウ ビルドで構成されるビルド ファミリがあります。ここでは、ボタンとテキストで構成される製品ファミリーを示します。各ウィンドウ コンポーネントは独自の階層構造を形成し、抽象的な機能説明を与える抽象的な役割と、さまざまなオペレーティング システムでの特定の実装を与える具体的なサブクラスを備えています。

上記の製品クラス図には、Button 階層構造と Text 階層構造という 2 つの製品階層構造があることがわかります。同時に、UNIX 製品ファミリと Windows 製品ファミリという 2 つの製品ファミリが存在します。 UNIX 製品ファミリは UNIX ボタン製品と UNIX テキスト製品で構成され、Windows 製品ファミリは Windows ボタン製品と Windows テキスト製品で構成されます。

製品オブジェクトに対するシステムの作成要件は、プロジェクトの階層構造によって満たされます。プロジェクトの階層構造には、UnixFactory と WindowsFactory という 2 つの特定のプロジェクト ロールがあります。 UnixFactory オブジェクトは Unix 製品ファミリーの製品の作成を担当し、WindowsFactory オブジェクトは Windows 製品ファミリーの製品の作成を担当します。これは、抽象ファクトリ パターンの適用です。抽象ファクトリ パターンの解決策は次のとおりです:

明らかに、システムは特定のオペレーティング システムのウィンドウ環境でのみ実行でき、別のオペレーティング システムでは実行できません。同時に。したがって、システムは実際には、同じ製品ファミリーに属する製品のみを消費できます。

現代のアプリケーションでは、抽象ファクトリー パターンの使用範囲が大幅に拡大され、システムは特定の製品ファミリーのみを使用する必要がなくなりました。

概要:

単純なファクトリ パターン、ファクトリ メソッド パターン、抽象的なファクトリ パターンのいずれであっても、それらはすべてファクトリ パターンに属しており、形式と特性が非常に似ています。それらの最終的な目標は分離することです。これを使用する場合、このパターンがファクトリ メソッド パターンであるか抽象ファクトリ パターンであるかを心配する必要はありません。これらの間の進化はしばしば混乱を招くためです。新しい要件が発生すると、使用しているファクトリ メソッド パターンがわずかに変更され、新しいメソッドが追加されることがよくあります。クラス内の製品は異なる階層構造の製品ファミリを構成するため、抽象ファクトリになります。抽象ファクトリ パターンの場合、提供される製品が製品ファミリを構成しないように 1 つのメソッドが削減されると、ファクトリ メソッド パターンに進化します。

したがって、ファクトリーパターンを使用するときは、結合を減らすという目的が達成されるかどうかだけを気にする必要があります。

JAVA デザイン パターンの Abstract Factory Pattern に関連するその他の記事については、PHP 中国語 Web サイトに注目してください。

関連記事:

Javaで抽象ファクトリパターンを実装するための具体的なコードを詳しく解説

PHPの単純ファクトリパターン、ファクトリメソッドパターン、抽象ファクトリパターンの比較

PHPオブジェクト指向開発 -抽象的な工場パターン