JAVAデザインパターン ファクトリパターン（シンプルファクトリパターン＋ファクトリメソッドパターン）

オブジェクト指向プログラミングでは、new 演算子を使用してオブジェクト インスタンスを生成するのが最も一般的な方法です。 new 演算子はオブジェクト インスタンスの構築に使用されます。ただし、場合によっては、新しいオペレーターがオブジェクトを直接生成すると、問題が発生することがあります。たとえば、多くのタイプのオブジェクトを作成するには、一連の手順が必要です。オブジェクトの初期設定を計算または取得する必要がある場合や、必要なオブジェクトを生成する前に、生成するサブオブジェクト インスタンスを選択する必要があります。 。 このような場合、新しいオブジェクトの作成は、より大型の機械のギア トランスミッションのような単なる操作ではなく、「プロセス」です。

パターンの問題: オブジェクト インスタンスを構築する詳細や複雑なプロセスを気にせずに、オブジェクト インスタンスを簡単かつ便利に構築するにはどうすればよいでしょうか?

解決策: オブジェクトを作成するための工場を構築します

実装:

1. はじめに
1) 工場時代はまだありません: 産業革命がなければ、顧客が BMW 車を望んでいる場合、一般的なアプローチは次のとおりです。お客様がBMW車を作成して使用します。
2) 単純な工場モデル: その後、産業革命が現れました。ユーザーはBMW車を作成する必要はありません。なぜなら、顧客はBMWを作るのを手伝ってくれる工場を持っているからです。この工場は彼が望むどんな車でも作ることができます。たとえば、320iシリーズの車が欲しいです。この工場はこのシリーズの自動車を製造しています。つまり、工場で製品を作ることができるのです。
3) 工場方式モデルの時代: 顧客を満足させるために、320i、523i、30li などの BMW 車シリーズがますます増えており、1 つの工場ですべての BMW シリーズを製造することはできません。その結果、複数の特定工場が分離されました。それぞれの特定の植物が一種のシリーズを作成します。つまり、特定のファクトリ クラスは特定の製品を 1 つだけ作成できます。しかし、BMW の工場は依然として抽象的なものです。車を生産するには特定の工場を指定する必要があります。

4) 抽象的なファクトリーモデルの時代: 顧客の要求がますます高くなるにつれて、BMW 車にはエアコンを装備する必要があります。そこで工場はBMW車と必要なエアコンの生産を開始しました。

最終的に、顧客は BMW の販売員に「523i エアコン付きの車が欲しい」と言うだけで済み、販売員は直接 523i エアコン付きの車を彼に渡します。 523i エアコン付き BMW 車を自分で作成する代わりに。

これがファクトリー モードです。

2. 分類
ファクトリ パターンは主に、オブジェクトを作成するための遷移インターフェイスを提供し、オブジェクト作成の特定のプロセスを保護および分離して、柔軟性を向上させるという目的を達成します。
ファクトリー パターンは 3 つのカテゴリに分類できます:

1) シンプル ファクトリ パターン (Simple Factory)
2) Factory Method パターン (Factory Method)
3) Abstract Factory パターン (Abstract Factory)

これら 3 つのパターンは上から順に下部 徐々に抽象化され、より一般的になります。
GOF は、書籍『デザイン パターン』の中で、ファクトリ パターンをファクトリ メソッド パターン (Factory Method) と抽象ファクトリ パターン (Abstract Factory) の 2 つのカテゴリに分類しています。

Simple Factory パターン (Simple Factory) は Factory Method パターンの特殊なケースと考えてください。この 2 つは同じカテゴリに分類されます。

3. 違い
ファクトリ メソッド パターン:
抽象プロダクト クラスは複数の特定のプロダクト クラスを派生できます。
抽象ファクトリ クラスは、複数の具象ファクトリ クラスを派生できます。
各特定のファクトリー クラスは、特定の製品クラスのインスタンスを 1 つだけ作成できます。
抽象ファクトリ パターン:
複数の抽象製品クラス。各抽象製品クラスは複数の特定の製品クラスを派生できます。
抽象ファクトリ クラスは、複数の具象ファクトリ クラスを派生できます。
各特定のファクトリ クラスは、特定の製品クラスの複数のインスタンスを作成できます。
違い:
ファクトリ メソッド パターンには抽象製品クラスが 1 つだけありますが、抽象ファクトリ パターンには複数の抽象製品クラスがあります。
ファクトリ メソッド パターンの具象ファクトリ クラスは、特定の製品クラスのインスタンスを 1 つだけ作成できますが、抽象ファクトリ パターンは複数のインスタンスを作成できます。
どちらも利用可能です。

4. シンプルなファクトリ パターン
新しいオブジェクトを作成するためのファクトリ (関数またはクラス メソッド) を作成します。
ディストリビューションの説明の紹​​介: 最初から。顧客は自分だけの BMW 車を作成し、それを使用します。

public class BMW320 {  
    public BMW320(){  
        System.out.println("制造-->BMW320");  
    }  
}  
  
public class BMW523 {  
    public BMW523(){  
        System.out.println("制造-->BMW523");  
    }  
}  
  
public class Customer {  
    public static void main(String[] args) {  
        BMW320 bmw320 = new BMW320();  
        BMW523 bmw523 = new BMW523();  
    }  
}

顧客は車の作り方を知る必要があり、顧客と車は密接に結びついています。その結合を減らすために、ファクトリークラスが登場し、BMWを作るためのすべての操作詳細が配置されています。工場と顧客は、工場の作成メソッドを直接使用して、作成の詳細を知らなくても、希望する BMW モデルを渡します。これが産業革命です。単純な工場パターン

、つまり、私たちが工場を作成します。新しいオブジェクトを作成するクラスメソッド。写真に示すように:

製品カテゴリ:

abstract class BMW {  
    public BMW(){  
          
    }  
}  
  
public class BMW320 extends BMW {  
    public BMW320() {  
        System.out.println("制造-->BMW320");  
    }  
}  
public class BMW523 extends BMW{  
    public BMW523(){  
        System.out.println("制造-->BMW523");  
    }  
}

工場カテゴリ:

public class Factory {  
    public BMW createBMW(int type) {  
        switch (type) {  
          
        case 320:  
            return new BMW320();  
  
        case 523:  
            return new BMW523();  
  
        default:  
            break;  
        }  
        return null;  
    }  
}

顧客カテゴリ:

public class Customer {  
    public static void main(String[] args) {  
        Factory factory = new Factory();  
        BMW bmw320 = factory.createBMW(320);  
        BMW bmw523 = factory.createBMW(523);  
    }  
}

简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单：定义一个用于创建对象的接口。
先来看看它的组成：
1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑，用来创建产品
2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。
3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在Java中由一个具体类实现。

下面我们从开闭原则（对扩展开放；对修改封闭）上来分析下简单工厂模式。当客户不再满足现有的车型号的时候，想要一种速度快的新型车，只要这种车符合抽象产品制定的合同，那么只要通知工厂类知道就可以被客户使用了。所以对产品部分来说，它是符合开闭原则的；但是工厂部分好像不太理想，因为每增加一种新型车，都要在工厂类中增加相应的创建业务逻辑（createBMW(int type)方法需要新增case），这显然是违背开闭原则的。可想而知对于新产品的加入，工厂类是很被动的。对于这样的工厂类，我们称它为全能类或者上帝类。
我们举的例子是最简单的情况，而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝累坏了，也累坏了我们这些程序员。
于是工厂方法模式作为救世主出现了。 工厂类定义成了接口,而每新增的车种类型,就增加该车种类型对应工厂类的实现,这样工厂的设计就可以扩展了,而不必去修改原来的代码。
五、工厂方法模式
工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。
工厂方法模式组成：
1)抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
2)具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
3)抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
4)具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。
工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活 起来——当有新的产品产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有 的代码。可以看出工厂角色的结构也是符合开闭原则的！

代码如下：

产品类：

abstract class BMW {  
    public BMW(){  
          
    }  
}  
public class BMW320 extends BMW {  
    public BMW320() {  
        System.out.println("制造-->BMW320");  
    }  
}  
public class BMW523 extends BMW{  
    public BMW523(){  
        System.out.println("制造-->BMW523");  
    }  
}

创建工厂类：

interface FactoryBMW {  
    BMW createBMW();  
}  
  
public class FactoryBMW320 implements FactoryBMW{  
  
    @Override  
    public BMW320 createBMW() {  
  
        return new BMW320();  
    }  
  
}  
public class FactoryBMW523 implements FactoryBMW {  
    @Override  
    public BMW523 createBMW() {  
  
        return new BMW523();  
    }  
}

客户类：

public class Customer {  
    public static void main(String[] args) {  
        FactoryBMW320 factoryBMW320 = new FactoryBMW320();  
        BMW320 bmw320 = factoryBMW320.createBMW();  
  
        FactoryBMW523 factoryBMW523 = new FactoryBMW523();  
        BMW523 bmw523 = factoryBMW523.createBMW();  
    }  
}

 工厂方法模式仿佛已经很完美的对对象的创建进行了包装，使得客户程序中仅仅处理抽象产品角色提供的接口，但使得对象的数量成倍增长。当产品种类非常多时，会出现大量的与之对应的工厂对象，这不是我们所希望的。