工場出荷時のモデルタイプのモデルを作成するための[デザインモード]

githubのリポジトリ住所：github.com/qiudao12345 ...

I.はじめに

Factoryパターン（ファクトリパターン）は、Javaは、最も一般的に使用されるデザインパターンの一つです。デザインパターンのこのタイプのオブジェクトを作成するための最良の方法を提供し、スキーマを作成します属します。ファクトリモードでは、我々はあなたがオブジェクトを作成するときに論理を作成するには、クライアントを公開していないだろう、と共通のインターフェースを使用して新しく作成されたオブジェクトを指すように

工場出荷時のモデルに属しているスキーマを作成するには、スキーマの記事を作成し、それはまた、シングルトンに属し、私を言及し、[デザインモード] -おそらく、シングルトンの最も詳細な説明である、それはどのような違いを生むのでしょうか？

答え：のメモリ内のオブジェクトのフォーカスシングルトンユニークさが、焦点は工場出荷時のモデルで作成プロセスの対象と内容の複雑さ隠す、オブジェクトの透明度、簡素化を構築するプロセスを。

PS：ビルドプロセスの詳細を非表示に端を要求すると、あまりにも長い間このアイデアのコアモジュールまたはコードとしてFactoryパターンを使用すると言うことができる工場モデルの核となるアイデア。工場出荷時のパターンは、唯一異なるシナリオに言及し、次の3つの工場ながら、それとの間の単純な区別の工場モデルを異なる実装を持つことができます

1.シンプル工場

GOFは23個のデザインパターンと話をして実際に簡単な工場出荷時のパターンが含まれていませんが、パターンがしばしば出会いです

1.1導入シーン

携帯電話を購入する1.11暁明

ボブは2台の電話機、キビ電話、Huawei社の携帯電話を購入したいと考えています。暁明は、これら2台の携帯電話を購入する場合は通常の状況下で、彼は何をする必要があるかもしれないです

• 1.、電話を開き、モールのキビを入力し、モールを入力するキビ、携帯電話の対応機種を見つけ、受注
• 2.服は、質問をされた購入、この多くの問題を、外出乗って、Huawei社の携帯電話店に、携帯電話の対応機種を選ぶために変え、彼はOPPO携帯電話場合は、1つを購入したい場合は？あなたはモールOPPOの注文に行く必要はありませんか？

それはちょうどあなたが何を携帯電話のモデル、そしてプラットフォームが自動的にあなたに電話を送信するために欲しいものを言って、携帯電話のすべてのブランドを購入するために、公共のプラットフォームに従事することはできませんか？

これは、工場の思考パターンです！

工場出荷時のモデルが提供する統一されたインタフェースは、我々は簡単に自分の具体的な詳細に注力することなく、目的のオブジェクトを取得することができます

UMLクラス図、単純なファクトリパターンで次の一見

1.2 UML図。

ここでは三つの主要な役割があります

• 1. 要約製品（電話番号）：機能拡張を容易にするために製品の抽象工場出力、
• 2. 特定の製品（XiaomiPhone） ：製品の抽象的な具体的な実現
• 3. 工場（し、SimpleFactory） ：渡されたパラメータの構築とは、特定の製品を返します。

このモードでは、コールのみに対応する製品情報を渡し、ファクトリオブジェクトを保持する必要が終了し、あなたはそれらの特定のケースの作成プロセスを気にして詳細情報を作成することはできません、目的のオブジェクトを取得するのは非常に簡単です。

達成するためのコードを見てみましょう

1.3コードの実装

（例には、単純にこのモードを表示するには、非常に複雑なサービスロジックを追加しません）

1.31抽象製品

/**
 * 手机
 * @author qiudao
 */
public interface Phone {
    // 打印品牌
    void printBrand();
}
复制代码

1.32特定の製品

Huawei社の携帯電話

/**
 * 华为手机
 * @author qiudao
 */
public class HuaweiPhone implements Phone{
    @Override
    public void printBrand() {
        //todo  复杂逻辑
        System.out.println("华为牌手机！");
    }
}

复制代码

ミレーの電話

/**
 * 小米手机
 * @author qiudao
 */
public class XiaomiPhone implements Phone{
    @Override
    public void printBrand() {
        //todo  复杂逻辑
        System.out.println("小米牌手机！");
    }
}
复制代码

1.33工場

/**
 * 简单工厂
 *
 * @author qiudao
 */
public class SimpleFactory  {
    // 小米的名
    public final static String XIAOMI_NAME = "xiaomi";
    //华为的名字
    public final static String HUAWEI_NAME = "huawei";
    /**获得手机**/
    public  Phone getPhone(String name) {
        Phone phone;
        // 静态编码校验
        if (XIAOMI_NAME.equals(name)) {
            //todo  复杂逻辑
            phone = new XiaomiPhone();
        } else if (HUAWEI_NAME.equals(name)) {
            //todo  复杂逻辑
            phone = new HuaweiPhone();
        } else {
            throw new NullPointerException("无对应手机");
        }
        return phone;
    }
}
复制代码

1.34テスト

/**
 * 测试简单工厂
 * @author qiudao
 */
public class TestSimpleFactory {
    public static void main(String[] args) {
        // 创建工厂
        SimpleFactory factory = new SimpleFactory();
        Phone huaweiPhone = factory.getPhone(SimpleFactory.HUAWEI_NAME);
        huaweiPhone.printBrand();
        Phone xiaomiPhone = factory.getPhone(SimpleFactory.XIAOMI_NAME);
        xiaomiPhone.printBrand();
    }
}
复制代码

2.ファクトリメソッド

私たち上記の単純なファクトリパターン、あなたはVIVO電話を追加したい場合は、この方法では、その後、私たちは簡単に目的のオブジェクトを取得できるようにすることができますが、非常に深刻な問題がある、つまり、貧しい人々スケーラビリティが、我々は必要

• 新VIVO電話カテゴリVivoPhone
• 変更SimpleFactory.getPhone（）に非常に反し方法開閉原理を、そして一方では、人々は全体的な論理フローは拡張子が変更された上で非常に当てにならない動物である、問題を引き起こすことは容易です。一方、論理的に単一のクラスに結合されたすべての、コードの結合が非常に高くなり、システム設計は満たしていない高凝集し、低カップリング結合した原理を

したがって、この時間は、私たちは、Factory Methodパターンで自分自身を再配置する必要があります

製品固有のオブジェクトがインスタンス化されるべきである1を決定するために、サブクラスファクトリが完了するまで、工場のサブクラスを、製品の遅延の動作をインスタンス化するために。植物の親クラス（インターフェース）製品オブジェクトのパブリックインターフェイスの定義を担当し、サブクラスの工場があります特定の製品のオブジェクトの作成を担当。

2.1導入シーン

最後のシーンでは、すべての携帯電話端末メーカーのための共通プラットフォームは、それを買ってきたので、誰かが携帯電話を購入したい場合、彼はすぐに彼に電話を与えることができます。しかし、問題は、より多くの携帯電話のブランドとして、この発見プラットフォームのボスは、プラットフォームは、自分の携帯電話を買うのに十分なお金ではありません！これはそれを行う方法ですか？

今回は、誰かが新しいモデルを提案しています。

• 暁明、必要に応じてマーケティングセンターに従事する、すべての携帯電話メーカーは、停滞の対応するブランドを見つけ、その後、直接マーケティングセンターに、センターに定住しています。次に、新しい携帯電話メーカーが表示された場合、その後、ちょうどプラットフォームが上のすべての携帯電話のすべてのブランドを購入する必要がないように、彼らは、ライン上のよどみ点におけるマーケティングセンターを設定してみましょう、それを彼らと携帯電話を買います

これは、ファクトリメソッドの核となるアイデアで、我々は見てのUMLマップを取ります

2.2 UML図を用いて説明しました。

4つの役割があります。

• 1. 抽象製品（電話）：シンプルな工場で
• 2. 特定の製品（HuaweiPhone） ：シンプルな工場で
• 3. 抽象ファクトリー（工場の）：義務の下抽象製品のインターフェースを作成します
• 4. 特定の植物（HuaweiPhoneFactory） ：工場を使用し、発信者によって決定される特定の製品工場を作ります

特定の製品を追加する必要がある場合は、あなただけに必要

• 1.要約製品インターフェイスの製品固有の実装を作成します
• 2.特定の製品の工場を作成し、抽象ファクトリインタフェースを実装します
• 3.呼び出すためにどの工場を決める最後の呼び出し

2.3コードの実装

2.31抽象製品

/**
 * 手机
 * @author qiudao
 */
public interface Phone {
    // 打印品牌
    void printBrand();
}
复制代码

2.32特定の製品

Huawei社の携帯電話

/**
 * 华为手机
 * @author qiudao
 */
public class HuaweiPhone implements Phone{
    @Override
    public void printBrand() {
        System.out.println("华为牌手机！");
    }
}

复制代码

ミレーの電話

/**
 * 小米手机
 * @author qiudao
 */
public class XiaomiPhone implements Phone{
    @Override
    public void printBrand() {
        System.out.println("小米牌手机！");
    }
}
复制代码

2.33抽象ファクトリー

/**
 * 工厂接口
 * @author qiudao
 */
public interface Factory {
    // 拿到手机
    Phone getPhone();
}
复制代码

2.34コンクリート工場

Huawei社の携帯電話

/**
 * 工厂方法的具体工厂
 * @author qiudao
 */
public class HuaweiPhoneFactory implements Factory{
    @Override
    public Phone getPhone() {
        //todo  复杂逻辑
        return new HuaweiPhone();
    }
}
复制代码

ミレーの電話

/**
 * 工厂方法的具体工厂
 * @author qiudao
 */
public class XiaomiPhoneFactory implements Factory{
    @Override
    public Phone getPhone() {
        //todo  复杂逻辑
        return new XiaomiPhone();
    }
}
复制代码

2.35テスト

/**.
 * 测试工厂方法
 * @author qiudao
 */
public class TestFactoryMethod {
    public static void main(String[] args) {
        System.out.println("工厂方法测试.......");
        Factory xiaomiPhoneFactory  = new XiaomiPhoneFactory();
        Phone xiaomiPhoe = xiaomiPhoneFactory.getPhone();
        xiaomiPhoe.printBrand();
        HuaweiPhoneFactory huaweiPhoneFactory = new HuaweiPhoneFactory();
        Phone huaweiPhone = huaweiPhoneFactory.getPhone();
        huaweiPhone.printBrand();
    }
}
复制代码

3.抽象ファクトリー

私たちの上に私たちは、工場出荷時の方法は従う、Factory Methodパターン、工場の単純な比較を導入原則の開閉を植物の拡大の場合には元のコードに損傷が発生することはありません。

3.1導入シーン

資金調達プラットフォームは、今解決し、それが新たな問題を作成しました：顧客は新しい携帯電話を購入した後、あなたはまた、モデルによっては、対応する携帯電話のセットを購入する必要があります。これはああを行う方法ですか？顧客は、携帯電話のセットを購入した場合、携帯電話のああを販売低迷のマーケティングセンター、、それは問題が工場出荷時のパターンの導入に先立って行われることを意味するのでしょうか？

だから、新しいルールの担当者：各定住停滞は、携帯電話のセットの対応する販売サービスを提供しなければなりません

このちょうど新興問題に良い解決策

3.2 UML図を用いて説明しました。

  Abstract Factoryパターンは、明示的に特定のクラスを指定する必要がなく、関連または依存オブジェクトの家族を作成するためのインタフェースを提供します。これは、プロセスプラントの複数の組み合わせとして理解することができます。

ファクトリメソッドは、作成することで、同じレベルの製品を、抽象工場を提供して作成することです製品ファミリの機能を

• 同じレベルとは何ですか？製品ファミリーは何をするのですか？

このシーンの言葉代入すると、Huawei社の携帯電話とキビの電話は、製品の同じ学年で、携帯電話のセットのHuawei社の携帯電話のセットとキビの携帯電話のセットがあり、彼らはまた、製品の同じレベルです。

キビのキビの電話セットを持つ携帯電話は、同じ製品ファミリ、Huawei社の携帯電話のセットを持つHuawei社の携帯電話、ではないが、同じことのようなものですが、彼らはHuawei社のブランドです、彼らは同じ製品ファミリに属します。

以下の図で表すことができます。

あなたが製品ファミリと製品レベルを理解すれば、私たちは抽象工場のUML図を見てください

ファクトリメソッドの種類に彼の役割は同じですが、異なるだけの事はある単一の製品を生産しない抽象工場のプラントが、製品ファミリーの事の生産

3.3コードの実装

3.31抽象製品

/**
 * 手机
 * @author qiudao
 */
public interface Phone {
    // 打印品牌
    void printBrand();
}
/**
 * 手机套
 * @author qiudao
 */
public interface PhoneCases {
    // 打印手机套名字
    void printCasesName();
}
复制代码

3.32特定の製品

/**
 * 华为手机
 * @author qiudao
 */
public class HuaweiPhone implements Phone{
    @Override
    public void printBrand() {
        System.out.println("华为牌手机！");
    }
}
/**
 * 小米手机
 * @author qiudao
 */
public class XiaomiPhone implements Phone{
    @Override
    public void printBrand() {
        System.out.println("小米牌手机！");
    }
}
/**
 * 华为手机壳
 * @author qiudao
 */
public class HuaweiPhoneCases implements PhoneCases{
    @Override
    public void printCasesName() {
        System.out.println("华为手机套");
    }
}
/**
 * 小米手机壳
 *
 * @author qiudao
 */
public class XiaomiPhoneCases implements PhoneCases {
    @Override
    public void printCasesName() {
        System.out.println("小米手机套");
    }
}
复制代码

3.33抽象ファクトリー

/**
 * 抽象工厂
 *
 * @author qiudao
 */
public interface AbstractFactory {
    // 获取手机
    Phone getPhone();

    // 获取手机套
    PhoneCases getPhoneCases();
}
复制代码

3.34コンクリート工場

/**
 * 华为工厂
 * @author qiudao
 */
public class HuaweiFactory implements AbstractFactory {
    @Override
    public Phone getPhone() {
        //todo  复杂逻辑
        return new HuaweiPhone();
    }

    @Override
    public PhoneCases getPhoneCases() {
        //todo  复杂逻辑
        return new HuaweiPhoneCases();
    }
}
/**
 * 小米工厂
 * @author qiudao
 */
public class XiaomiFactory implements  AbstractFactory {
    @Override
    public Phone getPhone() {
        //todo  复杂逻辑
        return new XiaomiPhone();
    }

    @Override
    public PhoneCases getPhoneCases() {
        //todo  复杂逻辑
        return new XiaomiPhoneCases();
    }
}

复制代码

3.35テスト

/**
 * 测试抽象工厂
 * @author qiudao
 */
public class TestAbstractFacoty {
    public static void main(String[] args) {
        System.out.println("抽象工厂测试");
        AbstractFactory xiaomiFactory = new XiaomiFactory();
        Phone xiaomiPhone = xiaomiFactory.getPhone();
        PhoneCases xiaomiPhoneCases = xiaomiFactory.getPhoneCases();
        xiaomiPhone.printBrand();
        xiaomiPhoneCases.printCasesName();
        AbstractFactory huaweiiFactory = new HuaweiFactory();
        Phone huaweiPhone = huaweiiFactory.getPhone();
        PhoneCases huaweiPhoneCases = huaweiiFactory.getPhoneCases();
        huaweiPhone.printBrand();
        huaweiPhoneCases.printCasesName();
    }
}
复制代码

4.工場出荷時のパターンの概要

なお、工場で上記の3つのモードがあり、UMLダイアグラムコードの実装は静的ではなく、上記の実施例は、より古典的な比較の代表的なものであること。私たちは、ビジネスに応じて行こう何回もカスタム拡張機能を必要とするか、我々は機能要件を実現することができるように、わずかにその構造を変更します。

例えば、上記抽象工場モデルは、抽象工場は抽象クラスとして定義され、そして次に抽象クラスで電話を組み立てる方法を定義することができる）（assemblePhoeを

 public void  assemblePhone(){
        System.out.println("开始组装");
        this.getPhone().printBrand();
        this.getPhoneCases().printCasesName();
        System.out.println("组装完成");
    }
复制代码

これは、拡張の数を達成することができます！

工場出荷時のパターンの3種類の長所と短所をまとめます

シンプル工場

利点

ファクトリクラスは、特定のクラスは、ファクトリクラスを使用して作成する必要があるオブジェクトは、外の世界が直接対象恥ずかし特定の製品を作成してから出てくることができるかどうかを判断するために与えられた外部の情報によると、全体のパターンへの鍵である必要な論理判断が含まれていますちょうどそれに責任を「消費」のオブジェクトにする必要があります。そして、あなたが作成し、どのように整理するために正確にどのようにこれらのオブジェクトが必要です。それぞれの責任と権限をクリアし、全体のソフトウェアアーキテクチャを最適化するのに役立ちます。

短所

あなたは新しいを追加する必要がある場合にのみ、考慮にクラスを取って、事前に作成することができ、ファクトリクラスは、すべてが、すべてのクラスに工場を作成し、集中ロジック内で責任の高いポリ配分の原則の違反の論理インスタンスを作成一元化ので、クラスは、我々は、ファクトリクラスを変更する必要があります。システムが成長している時間は、特定の製品カテゴリーである場合には、異なる基準に従って異なるインスタンスの工場のニーズによって作成された要件があるかもしれません。この判断と絡み合って、製品の特定の種類の条件の判断は、それがモジュール機能の普及を回避することは困難である、システムの維持・拡大は非常に否定的です

ファクトリメソッド

利点

単純な植物コントラストは、最大の利点は、ファクトリメソッドは、結合システムを減らす、開閉の原理に沿って元の構造変化の拡張を必要としないです。

短所

すべての新製品は、システムの複雑さを増す、長期的には洪水クラスを引き起こす可能性があり、クラスを追加する必要があります。

抽象ファクトリー

利点

製品ファミリーのコンセプトを増やし、工場は様々な製品を生産することができ、クラスの増殖を避けるために、ある程度のファクトリクラスの数を減らすことができます。同じ製品ファミリ連携動作の一部の間の積は、符号量を低減するために、（例えば、携帯電話機は、上述した例に組み立てられる）を行ってもよいです。

短所

この方法の基本的な欠点は、抽象工場ながら、別の欠点は、例えば、Huawei社のブースのマーケティングセンターは、単に植物をできるようになります不要なコードを生成するだけでなく、その後、携帯電話のセットを販売する抽象ファクトリを使用したくない携帯電話を販売したい、十分に柔軟ではない、工場出荷時と同じです魚も鳥でもありません

5.ソース・アプリケーション

JDKまたはファクトリメソッドで使用される優れたオープンソースのフレームワークの多くを持っています。以下のリストは少しではなく、綿密な解釈

スレッドプールのフレームワークエグゼキュータ

エグゼキュータUML構造図は、上記で言及したが、それは、発信者用に作成された非表示にしますので、疑いもなく、それは、工場モデルの使用されないが、UMLそれは三種類の中ではあるが、迅速にスレッドプールを作成する方法の範囲を提供します複雑なプロセスと詳細スレッドプール。のみのシンプルなインターフェイスを公開します。

春の豆の容器

私は、初心者には多くの学生が春には、コードのこの作品を見ているだろうときと信じています

BeanFactory beanFactory = new ClassPathXmlApplicationContext("xxx");
Object obj = beanFactory.getBean("car");
复制代码

わかるように、このコードは、工場モデルにおいても使用され、実際には、コアはスプリング豆容器であり、容器全体は、次いで、工場出荷時に記憶されたオブジェクトインスタンスの開始時に、植物でgetBean（文字列のbeanName）又はgetBean （クラスclazz）オブジェクトのインスタンスを取得するには、むしろ新しいXXX（）の方法によるより、植物のインスタンスを取得します

コレクションでのiteratorメソッド

java.util.Collectionインタフェースが定義されている（）メソッドは、ファクトリメソッド抽象イテレータです。

イテレータの場合は（）コレクション抽象工場のための方法は、次のインターフェイスだけでなく、抽象工場のリストは、その後、ダウン他の特定の植物がArrayListを、ルートです。

java.util.Iteratorの抽象インタフェースは、反復子抽象製品だけでなく、他の特定のArrayListIterator製品以下のように、製品のルートです。

異なるイテレータクラスコンクリート工場を使用する方法は、異なる特定の製品の例を得ることができます。

SqlSessionFactoryでMyBatisの

指定されたデータベースからSQLSESSIONを確立するためのSqlSessionFactoryは、デフォルトの実装クラスはDefaultSqlSessionFactoryが、必要であれば、開発者は、独自のSqlSessionFactoryを実装することができますし、これは古典的なファクトリメソッドに反映されています

すべてのすべてで、工場出荷時のパターンは、より困難になる理解することは困難ではないですが、時間にソースフレームワークに代入、それはまだ読んでいる、非常に一般的です。

エラーがある場合記事は、我々は、コメントをその翼を願っています！

githubのリポジトリ住所：github.com/qiudao12345 ...