Java デザインパターンのファクトリパターンの概要 (コード例)-＆＃＆チュートリアル-php.cn

この記事では、Java デザインパターンのファクトリパターン (コード例) を紹介します。必要な方は参考にしていただければ幸いです。

まえがき

前回の記事では、シングルトンパターンについて学び、シングルトンパターンを作成するいくつかの方法と最適な方法を紹介しました。この記事では、デザインパターンの中のファクトリパターンを主に単純ファクトリパターン、ファクトリメソッド、抽象ファクトリパターンに分けて紹介します。

シンプルファクトリパターン

シンプルファクトリパターンは作成パターンであり、静的ファクトリメソッドパターンとも呼ばれます。単純なファクトリパターンでは、ファクトリオブジェクトを使用して、どの製品クラスインスタンスを作成するかを決定します。この呼び出しでは、ファクトリクラスに必要なタイプを伝えるだけでよく、ファクトリクラスはプロダクトクラスファクトリの必要なサブクラスを返します。ファクトリーパターンの中で最もシンプルなものと言えます。

たとえば、私たちはコンピューターでゲームをすることがよくありますが、プレイしたいゲームをコンピューターに伝えるだけで、コンピューターはゲームがどのように動作するかを気にする必要はありません。
次のコードでそれに応じて説明できます。

最初に、ゲームをプレイするためのメソッドを含むゲーム一般クラスのインターフェイスを作成します。次に、それぞれのゲームクラスがこのクラスを継承してこのクラスのメソッドを実装し、最後にさまざまなゲームに応じてオブジェクトを作成するエンジニアリングクラスを作成します。
実装されたコードは次のとおりです:

コード例:

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    
    public static void main(String[] args) {
        Game game= ComputerFactory.playGame(LOL);
        Game game2= ComputerFactory.playGame(DNF);
        game.play();
        game2.play();
    }
}

interface Game{
    void play();
}

class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}


class ComputerFactory{
    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
     public static Game playGame(String game){
         if(LOL.equalsIgnoreCase(game)){
             return new LOL();
         }else if(DNF.equalsIgnoreCase(game)){
             return new DNF();
         }
         return null;
     }

ログイン後にコピー

出力結果:

正在玩LOL...
正在玩DNF...

ログイン後にコピー

単純なファクトリパターンを使用してこの関数を実装した後、ゲームのインスタンス化を配置していることがわかります。クラスをファクトリクラスに実装すると、オブジェクト作成の詳細が隠蔽され、その再生方法を知る必要はありません。ファクトリクラスを呼び出す方法だけを知る必要があります。また、ファクトリクラスによって渡される型の値を変更するだけで済むため、切り替えるのに便利です。
しかし、新しいゲームクラスを追加する必要がある場合は、新しいインターフェイスを定義してから、ファクトリークラスに判断ブランチを追加する必要があります。少量であれば問題ありませんが、量が多いとさらに面倒になりますし、これもオープンクローズの原則に違反します。

ファクトリメソッドパターン

ファクトリメソッドパターンは、Java で最も一般的に使用されるデザインパターンの 1 つであり、作成パターンです。オブジェクトを作成するためのインターフェイスを定義し、そのサブクラスにどのファクトリクラスをインスタンス化するかを決定させます。ファクトリパターンは、サブクラスが作成されるまで作成プロセスを遅らせます。

単純なファクトリパターンでは、サブクラスを追加するときにファクトリクラスに判断分岐も追加する必要があり、これはオープンクローズの原則に違反することがわかりました。ファクトリメソッドパターンは主にこの問題を解決します。

ゲームをプレイする上記の例は、ここでの各ゲームが独自のゲームファクトリクラスによって実装されていることを除いて、ここでも使用されています。主な違いは、ファクトリクラスが 1 つではなく複数あることです。これにより、結合度が減少します。新しいゲームクラスを追加する場合は、ファクトリクラスを追加するだけで済み、オープンクローズの原則が完全に守られます。

上記のコードを変更した後、対応するコードは次のように実装されます:

コード例:

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    private static final String WOW="WOW"; 

    public static void main(String[] args) {

        Game game3=new LOLFactory().playGame(LOL);
        Game game4=new DNFFactory().playGame(DNF);
        Game game5=new WOWFactory().playGame(WOW);
        game3.play();
        game4.play();
        game5.play();       
    }
    
interface Game{
    void play();
}


class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}

class WOW  implements Game{
    @Override
    public void play() {
        System.out.println("正在玩WOW...");
    }   
}


interface ComputerFactory2{
    Game playGame(String game);
}

class LOLFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new LOL();
    }
}

class DNFFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new DNF();
    }
}

class WOWFactory implements ComputerFactory2{
    @Override
    public Game playGame(String game) {
        return new WOW();
    }
}

ログイン後にコピー

出力結果:

正在玩LOL...
正在玩DNF...
正在玩WOW...

ログイン後にコピー

ファクトリメソッドパターンを使用した後、コードがより明確になり、スケーラビリティが向上したことがわかります。プロダクトを追加したい場合は、ファクトリクラスを拡張するだけで済みます。ただし、製品が追加されるたびに、具体的なクラスとオブジェクト実装ファクトリークラスを追加する必要があり、システムは複雑になります。
したがって、このモードを使用するかどうかに注意する必要があります。
このパターンを使用するより古典的なユースケースは、データベース言語を選択する際の有名な hibernate フレームワークです。ただし、単にオブジェクトを新規作成するだけの場合は、それを使用する必要はありません。使用すると、システムが複雑になります。

Abstract Factory Pattern

Abstract Factory Patternは、スーパーファクトリーの周りに他のファクトリーを作成することです。ギガファクトリーは他の工場の工場としても知られています。このタイプのデザインパターンは創造的なパターンであり、オブジェクトを作成するための最適な方法を提供します。つまり、特定のクラスを指定せずに、一連の関連オブジェクトまたは相互依存オブジェクトを作成するためのインターフェイスを提供します。

抽象ファクトリパターンはファクトリメソッドパターンよりも複雑で理解しにくいですが、拡張は簡単です。
抽象ファクトリーパターンは、同じタイプの製品サブカテゴリを 1 つのカテゴリにグループ化し、同じ抽象サブカテゴリを継承させて、それらをグループとして扱い、複数のグループを 1 つのファミリーにグループ化します。
たとえば、上記のゲームをまだプレイしている場合、LOLとWOWをPVPタイプのゲームと考えることもできますし、DNFとWOWをPVEタイプのゲームと考えることもできます。

対応する変更されたコードは次のとおりです:

コード例:

    private static final String LOL="LOL"; 
    private static final String DNF="DNF"; 
    private static final String WOW="WOW"; 
    
    public static void main(String[] args) {

        ComputerFactory3 cf3=new PVPFactory();
        cf3.playGame().play();
        cf3.playGame2().play();
        ComputerFactory3 cf4=new PVEFactory();
        cf4.playGame().play();
        cf4.playGame2().play();         
    }       
}


interface Game{
    void play();
}


class LOL implements Game{
    @Override
    public void play() {
        System.out.println("正在玩LOL...");
    }   
}

class DNF implements Game{
    @Override
    public void play() {
        System.out.println("正在玩DNF...");
    }   
}

class WOW  implements Game{
    @Override
    public void play() {
        System.out.println("正在玩WOW...");
    }   
}


interface ComputerFactory3{
     Game playGame();
     Game playGame2();
}

class PVPFactory implements ComputerFactory3{

    @Override
    public Game playGame() {
        return new LOL();
    }

    @Override
    public Game playGame2() {
        return new WOW();
    }   
}

class PVEFactory implements ComputerFactory3{

    @Override
    public Game playGame() {
        return new DNF();
    }

    @Override
    public Game playGame2() {
        return new WOW();
    }
    
}

ログイン後にコピー

出力結果:

正在玩LOL...
正在玩WOW...
正在玩DNF...
正在玩WOW...

ログイン後にコピー

在抽象工厂模式中，可以在不需要知道产品是怎么样的，只需知道是哪个工厂类就行了。我们也可以根据子类的共同的特性而将它们设计在一起，组成一个相同类型组，可以很方便的直接调用。但是相对的，产品族比较难以扩展，增加一个产品，需要增加相应的接口和实现类。例如某个品牌的手机，有不同系列，每个系列有不同的型号，如果只是增加型号的话，比较容易，但是相对的，增加某个系列就比较麻烦了。
所以我们在使用抽象工厂模式，也需要相应的结合实际场景来使用。