オブジェクトのみを構築するために私たちを助けるために、多くの人々は、工場出荷時のパターンは非常に簡単だと思いますが、ビルド工場があります。そこで、以下、次の質問にお答えしてみてください。
1は、工場出荷時のモードは、いくつかのカテゴリに分かれて？
2、デザインパターンのGOF 23種類、Factory MethodパターンとAbstract Factoryパターンの違いは何ですか？
3、どのようなGOFの単純なファクトリパターン23個のデザインパターンがありませんか？
4、簡単なファクトリパターン、Factory MethodパターンとAbstract Factoryパターンは、その問題を解決するには？違いは何ですか？
上記の4つの質問の場合は、そうでない場合は、この記事では、読みを継続する必要はなく、良い答えすることができ、私はあなたが次の記事を学ぶお勧めします。
工場出荷時のパターンの三種類{＃}のtoc_0
ファクトリモードは、次の3つのカテゴリに分けることができます。
-
1）単純なファクトリパターン（シンプルファクトリー）
-
2）ファクトリメソッドモデル（ファクトリメソッド）
-
3）抽象ファクトリー（抽象ファクトリー）
上から下、徐々に抽象的で、より一般的にこれらの3つのモデル。
ファクトリメソッドモデル（ファクトリメソッド）Abstract Factoryパターン（要約ファクトリー）：GOFでは、「デザインパターン」ブックファクトリーモードは2つのカテゴリに分類されます。
単純なファクトリパターン（単純工場）は、両方のクラスに分類される、モードの特別な場合を見るためにファクトリメソッドです。
デザインモードで3つの工場出荷時のパターン分類をすべてされているスキーマを作成しました。
抽象クラスのスキーマ（生成に関するパターン）インスタンス化プロセスを作成し、オブジェクトに別々のソフトウェア・モジュールとオブジェクトを使用して作成することができます。ソフトウェアのより明確な構造を作るために、これらのオブジェクトの外の世界は、唯一のより多くの単一責任の原則に沿ったもので、システム全体の設計を彼らの共通のインタフェースを知っておく必要がありますが、具体的な実装の詳細を知りません。
スキーマがどのような（何）の観点で作成された作成し、（誰が）作成者、（とき）を作成するときなど、ソフトウェア設計者のための可能な限り最大の柔軟性を提供します。
スキーマを作成すると、クラスのインスタンスを作成の詳細を隠し、彼らは目的を達成するために、システム全体を作成するために一緒に結合しているかの独立した隠されたオブジェクトによって達成されます。
Factoryパターンは、より重要なスキーマを作成することです。工場モデルの主な機能は、オブジェクトをインスタンス化するために私たちを支援することです。インスタンス化オブジェクトは植物によって達成されるため、プラントモデル名は、言葉が含まれている理由は、工場は新しい操作に置き換えられます。
このパッケージの利点は、オブジェクトの詳細の一例であり、特に、より複雑なライフサイクルまたは標的の例の場合では、集中管理されなければなりません。これは、スケーラビリティを持参し、あなたのシステムの変形量を最小限に抑えることができます。
次は3つの工場出荷時のパターンを紹介しました。
単純なファクトリパターン{＃1} toc_1
スキーマを作成するための単純なファクトリパターンは、静的ファクトリメソッド（静的ファクトリメソッド）モードとして知られている、所属します。シンプルなファクトリパターンは、製品クラスのどのような種類のインスタンスを作成するファクトリオブジェクトによって決定されます。シンプルなファクトリパターンは、工場出荷時のモデルファミリーは、最もシンプルで実用的なモデルは、異なる植物の実現の特別なモードとして理解することが可能です。
シンプルなファクトリパターンを導入する前に、我々は次の問題に対処しよう：
今、私たちは様々なアルゴリズムの間のデカップリングを達成するために、オブジェクト指向の正式な定義の計算機を使用します。次のようなクラスの主な用途は以下のとおりです。
// 计算类的基类
public abstract class Operation {
private double value1 = 0;
private double value2 = 0;
public double getValue1() {
return value1;
}
public void setValue1(double value1) {
this.value1 = value1;
}
public double getValue2() {
return value2;
}
public void setValue2(double value2) {
this.value2 = value2;
}
protected abstract double getResule();
}
//加法
public class OperationAdd extends Operation {
@Override
protected double getResule() {
return getValue1() + getValue2();
}
}
//减法
public class OperationSub extends Operation {
@Override
protected double getResule() {
return getValue1() - getValue2();
}
}
//乘法
public class OperationMul extends Operation {
@Override
protected double getResule() {
return getValue1() * getValue2();
}
}
//除法
public class OperationDiv extends Operation {
@Override
protected double getResule() {
if (getValue2() != 0) {
return getValue1() / getValue2();
}
throw new IllegalArgumentException("除数不能为零");
}
}
复制代码私はほかの操作を実行したいときは、次のコードを使用することができます。
public class Main {
public static void main(String[] args) {
OperationAdd operationAdd = new OperationAdd();
operationAdd.setValue1(10);
operationAdd.setValue2(5);
System.out.println(operationAdd.getResule());
}
}
复制代码私は減算を実行する必要があるとき、私はOperationSubクラスを作成するつもりです。言い換えれば、私は別の計算が異なるクラスを作成する必要があり、クラスの名前を知って明確にするために使用します。
そして、この繰り返しの作業は、実際に統一ファクトリクラスにクラスを作成することができます。シンプルなファクトリパターンは、次のような利点があります。
1は、呼び出し側はそれにその名前を知って、オブジェクトを作成したかったのです。
2、製品の具体的な実現は、製品のインターフェースでのみ当該発信者を遮蔽します。
シンプルなファクトリパターンの実装
実際には、簡単な工場のパターンと彼の名前は非常に簡単です。のは、その組成を見てみましょう：
工場：これは、このモードの中核である、それは特定のビジネスロジックやアービトレーション・ロジックが含まれています。それは、多くの場合、具体的なクラスのJavaによって達成されます。（OperationFactory）
製品：それは一般的にある特定の製品は、親クラスを継承するか、インタフェースを実装します。Javaではインターフェイスまたは抽象クラスによって実現。（動作）
ConcreteProduct：オブジェクトファクトリクラスは、この役割のインスタンスを作成しています。具象クラスのJavaで実現。以下の下でそれらの間（などOperationAdd \ OperationSub）との関係を示すクラス図には明らかです

元のクラスに基づいて、工場出荷時のクラス定義：
//工厂类
public class OperationFactory {
public static Operation createOperation(String operation) {
Operation oper = null;
switch (operation) {
case "+":
oper = new OperationAdd();
break;
case "-":
oper = new OperationSub();
break;
case "*":
oper = new OperationMul();
break;
case "/":
oper = new OperationDiv();
break;
default:
throw new UnsupportedOperationException("不支持该操作");
}
return oper;
}
}
复制代码クラスの後に工場を使用すると、オブジェクトを作成するファクトリを使用することができます：
Operation operationAdd = OperationFactory.createOperation("+");
operationAdd.setValue1(10);
operationAdd.setValue2(5);
System.out.println(operationAdd.getResule());
复制代码彼はその上に、クラス「+」に対応するパラメータを知っているような単純なファクトリパターンは、ユーザーがいる限り、そのクラスの追加ロジックの特定の名前との間の関係を実現するための計算を必要としません。
問題は、単純なファクトリパターンがあります
私たちは、このような平方根として、計算を追加する必要がある場合。今回は継承したクラスを定義する必要がありOperation、正方形のコードを達成したクラスを、。加えて、我々は変更する必要がありOperationFactory、クラスのコードをケースを追加します。これは明らかに開閉の原則に反しています。一つは、新製品を追加するため、ファクトリクラスは非常に受動的であると想像することができます。
私たちの例では、最も単純なケースです。実用的な用途において、製品は、マルチレベルのツリー構造である可能性が高いです。シンプルな工場は非常に適用できませんでした。
シンプルなファクトリパターンの概要
ファクトリクラスは、単純なファクトリパターンの鍵となります。これは、外部与えられた情報に基づいて、決定するために必要なロジックが含まれ、その特定のクラスのオブジェクトを作成するかどうかを決めます。ファクトリクラスを使用することにより、外の世界は、直接恥ずかしのオブジェクトを作成し、特定の製品から出てくることができ、ちょうどその上に「消費者」オブジェクトの原因であることが必要です。そして、あなたが作成し、どのように整理するために正確にどのようにこれらのオブジェクトが必要です。それぞれの責任と権限をクリアし、全体のソフトウェアアーキテクチャを最適化するのに役立ちます。
しかし、責任の高い凝集配分の原則に違反するすべての論理インスタンスを作成するに焦点を当てたファクトリクラスに、すべてのファクトリクラスに論理フォーカスを作成し、それが唯一の口座にクラスを取って、事前に作成することができ、あなたは新しいを追加する必要がある場合クラスは、次に我々は、ファクトリクラスを変更する必要があります。
システムが成長している時間は、特定の製品カテゴリーである場合には、異なる基準に従って異なるインスタンスの工場のニーズによって作成された要件があるかもしれません。この判断と絡み合って、製品の特定の種類の条件の判断は、モジュールの機能、システムの維持・拡大の拡大を回避することは困難である非常に不利です。
特定の解決にFactory Methodパターンでは、これらの欠点。
ファクトリメソッドパターン{＃1} toc_2
また、工場出荷時のモードとして知られているファクトリメソッドモデル（ファクトリメソッドパターン）は、仮想コンストラクタ（仮想コンストラクタ）モードまたはクラスに作成されたスキーマに属している多型植物（ポリモーフィック工場）モードと呼ばれます。
モードは、オブジェクト指向のデザインパターンの概念を達成するためのファクトリメソッドである「植物を。」他の生成に関するパターンのように、それはまた、オブジェクトの特定のタイプを指定せずにオブジェクトを作成する際に問題に対処します。
エッセンスFactory Methodパターンは、「作成したオブジェクトのインタフェースの定義が、のは、サブクラスがいたに延期許可したクラスをインスタンス化するクラスファクトリメソッドのどのインスタンスかを決定するために、このインタフェースを実装してみましょう。」です
この方法は、工場出荷時のモードを使用しています
ファクトリメソッドパターンとファクトリパターン、彼らは工場によってオブジェクトを作成するのは簡単ですが、それらの間の最大の違いはある- 「開閉の原則」Factory Methodパターンはに完全に準拠して完了するように設計されて
この方法は、以下の状況で、工場モードを使用することができます。
クラスは、クラスのオブジェクト必要と認識していません：Factory Methodパターン、クライアントはあなたが唯一の具体的なファクトリクラスによって作成された特定の製品のオブジェクトに対応する植物を知っている必要があり、クラス名、特定の製品カテゴリを知る必要はありませんが。クライアントは、製品固有のファクトリクラスを作成するために知っておく必要があります。
作成されたオブジェクトのサブクラスで指定されたクラス：ファクトリモード方法は、抽象クラスの工場でのみ製品インタフェースを作成する必要があり、オブジェクトが特定のオブジェクト指向の多型を作成するためにサブクラスによって決定することができますそして、リヒター置換原則は、プログラムが実行されている、オブジェクトのサブクラスを拡大するシステムが容易になり、親クラスのオブジェクトを上書きします。
タスクは、製品にサブカテゴリを作成するには、サブクラスの工場であるかもしれないものを気にせずに使用する場合、特定のクライアント、複数の植物のサブクラスのオブジェクトを作成するために、そして必要なときに動的に割り当てられ、特定のクラスファクトリクラスの名前にすることができ委託しますコンフィギュレーションファイルまたはデータベースに格納されています。
Factory Methodパターンの実装
Factory Methodパターンは、次の役割が含まれています。
製品：抽象物
Operation（）ConcreteProduct：特定の製品（
OperationAdd）工場：抽象ファクトリー（
IFactory）ConcreteFactory：コンクリート工場（
AddFactory）

電卓を使用する例もあります。保持Operation、OperationAdd、OperationDiv、OperationSub、OperationMul同じ、簡単な変更ファクトリクラスファクトリモードのいくつかの他の方法の場合には（OperationFactory）。大きな工場の元「汎用」カテゴリーを交換し、ファクトリメソッドではなく、ここで使用しました：
//工厂接口
public interface IFactory {
Operation CreateOption();
}
//加法类工厂
public class AddFactory implements IFactory {
public Operation CreateOption() {
return new OperationAdd();
}
}
//除法类工厂
public class DivFactory implements IFactory {
public Operation CreateOption() {
return new OperationDiv();
}
}
//除法类工厂
public class MulFactory implements IFactory {
public Operation CreateOption() {
return new OperationMul();
}
}
//减法类工厂
public class SubFactory implements IFactory {
public Operation CreateOption() {
return new OperationSub();
}
}
复制代码あなたがクライアント上で追加の操作を実行したい場合は、この方法では、次のような方法が必要です。
public class Main {
public static void main(String[] args) {
IFactory factory = new AddFactory();
Operation operationAdd = factory.CreateOption();
operationAdd.setValue1(10);
operationAdd.setValue2(5);
System.out.println(operationAdd.getResult());
}
}
复制代码ここでは、Factory Methodパターンが書き込まれています。
視点符号量から、このモデルファクトリメソッドは、単純なファクトリメソッドよりも複雑です。（動作）は、異なるクラスの動作は、対応する植物を持っています。多くの人々は、次の質問があります。
シンプルなファクトリパターンよりもはるかに複雑であるFactory Methodパターンのように見えますか？
ファクトリメソッドパターンは、自分自身に差がないオブジェクトを作成しますか？なぜ我々はいくつかの工場を思い付くでしょうか？
ここでは上記の二つの質問については、さらにどのようにFactory Methodパターンを理解します。
なぜオブジェクトを作成するファクトリを使用？
オブジェクトの作成パッケージ
顧客が必要とする製品を作成するためのファクトリメソッドパターン、ファクトリメソッドではなく、顧客に特定の製品クラスは、この詳細をインスタンス化されるかを隠して、ユーザーがのみ作成心配せずに、対応する製品のために必要な植物を心配する必要があります詳細は、あるいはクラスの特定の製品カテゴリの名前を知っています。
多型のプラント設計は、製品の役割と性格に基づいてキーFactory Methodパターンです。**これは、植物が自律的にどのように完全にコンクリート工場でカプセル化されたオブジェクトの詳細を作成するために作成されたものを製品オブジェクトを決定し、することができます。**理由ファクトリメソッドはまた、多型工場モードと呼ばれる同じ抽象親クラスを持つ特定のファクトリクラスのすべてのため。
なぜ、各オブジェクトには、あなたは別の工場を持っていたいですか？
「 - クローズ原則オープン」に沿って、
主な目的は、切り離すことです。システムに新製品を追加する場合は、インターフェイス抽象化、抽象工場と製品は、クライアントを変更することなく提供しています変更する必要があり、他の具体的な植物やコンクリート製品を変更する必要がなく、それに特定の植物や特定の製品を追加します。このため、システムの拡張性は、開閉の原則」と非常に良い、完全準拠になります。
これらは、ファクトリメソッドの利点です。しかし、工場のモデルは、いくつかの不十分な側面があります。
新製品を追加するときに、あなたが特定の製品の新しいクラスを記述することなく、対応する具体的なファクトリクラスを提供する必要があり、クラスのシステムは増加の対の数は、ある程度のシステムの複雑さは、より多くのがありますこのクラスは、いくつかの追加のオーバーヘッドシステムをもたらすでしょう、コンパイルして実行する必要があります。
抽象化レイヤの導入を必要とし、クライアントコードを使用して抽象化レイヤで定義され、アカウントにシステムのスケーラビリティを取って、システムは、抽象化と理解の困難さを増加させ、実装された場合DOM、反射技術を使用する必要があり、システムを実装することの難しさを増します。
Factory Methodパターンの概要
Factory MethodパターンはさらにシンプルかつAbstract Factoryパターンを促進することです。
オブジェクト指向のポリモーフィズムの使用、シンプル保持モードファクトリメソッドファクトリパターンの利点に、その欠点を克服するため。
Factory Methodパターンでは、ファクトリクラスのコアは、もはやすべての製品を作成するための責任がありませんが、それを行うには、特定のサブクラスを作成していきます。コアクラスは、Factory Methodパターンは、システムが役割を変更することなく、工場で新製品を投入できるようにすることができますこのような詳細をインスタンス化された製品クラス、責任を負いません実装する必要があります植物固有のインタフェースに対してのみ責任を与えられています。
プラントモデルの主な利点は、製品の新しいクラスを追加することなく、既存のシステムを変更するための方法であり、オブジェクトの作成の詳細の包装製品、システムは優れた柔軟性と拡張性を持ち、同時に新製品を追加欠点は、新しいを追加する必要があります植物は、システムクラスのペアの数を増加させることで、その結果、ある程度、システムの複雑さを増大させます。
Abstract Factoryパターン{＃1} toc_3
抽象ファクトリー（Abstract Factoryパターン）：自分の具象クラスを指定せずに、関連または依存オブジェクトインターフェイスのシリーズを作成します。また、キットとして知られているAbstract Factoryパターン、スキーマ・オブジェクトの作成に属します。
抽象工場モデルは、同じ製品ファミリの植物をカプセル化することができる分離する方法を提供します。通常の使用では、クライアントプログラムは、抽象工場の具体的な実装を作成し、インターフェイスとして主題を作成するために、抽象具象オブジェクトファクトリを使用する必要があります。共通のインタフェースのみこれらのクライアントオブジェクトを使用しているため、クライアントは、これらのメソッドの内部では、工場から得られたオブジェクトの特定のタイプを知っている（またはケア）する必要はありません。Abstract Factoryパターンの実装では、個別のオブジェクトの集合とそれらの一般的な使用を詳述します。
製品ファミリ
製品ファミリの下にあるかを知る：製品は、製品の組成物に関連したさまざまな階層構造、家族の関数です。ファミリーカーと商用車の家族：次の例のように、2つの製品ファミリがあります。

Abstract Factoryパターンを使用しています
Abstract Factoryパターンや工場法パターンが、オープンに準拠している - の原則を閉じました。その差は、ファクトリメソッドパターンは、特定の製品を高めるために、工場の対応する増加することです。しかし、Abstract Factoryパターンは、製品の新しいタイプは、特定の植物を追加する必要がある場合のみです。つまり、工場出荷時のモデルのファクトリメソッドは、1つの特定の製品を作成することができます。そして、工場Abstract Factoryパターンは、クラスタイプに属する特定の製品のさまざまなを作成することができます。工場数は、単純なファクトリパターンとFactory Methodパターン間の製品を作成することができます。
抽象的な工場モデルは、次の場合に使用することができます。
システムは、製品クラスのインスタンスが作成される方法に依存してはならない、工場出荷時のパターンのすべてのタイプのために重要である詳細と表現の組み合わせ、。
システムは、複数の製品ファミリ、前記各時間だけ1つの製品ファミリを持っています。
製品には制約がシステムの設計に反映されている必要があり、一緒に使用される同じ製品ファミリに属しています。
システムは、クライアントが特定の実装に依存しないように、製品のすべてが、同じインターフェースで表示され、製品のクラスライブラリを提供します。
Abstract Factoryパターンの実装
Abstract Factoryパターンは、次の役割が含まれています。
この方法は、抽象物を生成する宣言するために使用：AbstractFactory（抽象ファクトリー）
ConcreteFactory（特に植物）：抽象工場は抽象製品は、各製品が製品を階層構造に配置され、製品のファミリーを構成する特定の製品のセットを生成し、生成された宣言されたメソッドを実装します。
AbstractProduct（抽象製品）：各製品インターフェイスのステートメント、製品の抽象積で定義された抽象ビジネス方法。
製品（製品固有）：インタフェース製品で定義された抽象ビジネスメソッドを達成するために、被写体の特定の製品の特定の工場の生産を定義します。
本稿の例として、自動車を作る車のファウンドリの一例。私たちは、両社が車を製造メルセデスとテスラのために責任がある、私たちは車のファウンドリあると仮定します。私たちは、単にメルセデス・ベンツの車が車に燃料を補給する必要があるとして、車はテスラのために充電する必要が理解しました。メルセデスのスポーツカー、商用車が含まれていたテスラはまた、メルセデス・ベンツの乗用車と商用車を含め、2つです。

上記のシナリオでは、我々は車を入れることができますし、商用車は別の、商用車は別々の工場を持って作成するために、スポーツカー工場のために処理しました。このように、将来は他のどのベンダー、その後は限り我々は、工場の導入を再作成する必要はありませんよう車、スポーツカーや商用車を作るのを助けるかどうかです。私たちは、このようなSUV車等の車両の一つの他のタイプを、追加したい場合は同様に、我々は車や商用車のものに変更を加える必要はありません。
ここでは抽象的製品、メルセデスとテスラ車です。
public interface BenzCar {
//加汽油
public void gasUp();
}
public interface TeslaCar {
//充电
public void charge();
}
复制代码以下は、特定の製品、メルセデス・ベンツのスポーツカー、メルセデスベンツ商用車、テスラロードスター、テスラ商用車のとおりです。
public class BenzSportCar implements BenzCar {
public void gasUp() {
System.out.println("给我的奔驰跑车加最好的汽油");
}
}
public class BenzBusinessCar implements BenzCar{
public void gasUp() {
System.out.println("给我的奔驰商务车加一般的汽油");
}
}
public class TeslaSportCar implements TeslaCar {
public void charge() {
System.out.println("给我特斯拉跑车冲满电");
}
}
public class TeslaBusinessCar implements TeslaCar {
public void charge() {
System.out.println("不用给我特斯拉商务车冲满电");
}
}
复制代码ここでは抽象工場は次のとおりです。
public interface CarFactory {
public BenzCar getBenzCar();
public TeslaCar getTeslaCar();
}
复制代码以下は、特定の工場です。
public class SportCarFactory implements CarFactory {
public BenzCar getBenzCar() {
return new BenzSportCar();
}
public TeslaCar getTeslaCar() {
return new TeslaSportCar();
}
}
public class BusinessCarFactory implements CarFactory {
public BenzCar getBenzCar() {
return new BenzBusinessCar();
}
public TeslaCar getTeslaCar() {
return new TeslaBusinessCar();
}
}
复制代码偏った「開閉原則」
修正のために、拡張のためのオープンなシステムを必要とする「クローズ原則は、」その機能を拡張することによって強化され得る閉じました。2つの拡張機能を含む複数の製品と製品ファミリー階層構造の複数を含むシステムの場合：
「開閉の原則を」良いサポート、Factory Methodパターンを新製品ファミリを追加するだけで新しいコンクリート工場の増加に対応する必要がある、新しい製品ファミリを追加することができ、あなたは、コードを持っている必要はありません：製品ファミリを増やします任意の変更。
新製品階層を追加します。新製品の階層を追加するために、あなたは抽象ファクトリクラス、メソッド、クラスは、追加する必要がある工場のすべての新製品の生産を含むすべての工場の役割を、変更する必要はうまく対応していません「開閉原則。 "
このプロパティは、「開閉原則の」Abstract Factoryパターンの傾き、新製品の追加をサポートするために、斜めの方法で、Abstract Factoryパターンと呼ばれ、新製品グレードの新製品ファミリーの可用性を向上させることは容易ではなく、このような構造が増加し利便性を提供します。
Abstract Factoryパターンの概要
Abstract Factoryパターンは、その具象クラスを指定せずに、関連または依存オブジェクトインターフェイスのシリーズを作成しています。また、キットとして知られているAbstract Factoryパターン、スキーマ・オブジェクトの作成に属します。
最も抽象的で一般的な形式でファクトリパターンのすべての形態にAbstract Factoryパターン。
Abstract Factoryパターンの主な利点は、顧客が作成されているかを知る必要がないように、特定のクラスの生成を分離することで、具体的なファクトリクラスによって製品ファミリは、あるいはより便利な製品ファミリを増加するたびに、複数のオブジェクトを作成することができ、新しいコンクリート工場と製品ファミリを追加することは簡単です。主な欠点は、新製品の追加階層構造は非常に複雑であるということです、そしてサポートするために、すべての具体的なファクトリクラス抽象工場を変更する必要があり、「開閉の原理を、」プレゼンテーションの傾きを。
植物の対照の三種類{＃}のtoc_4
シンプルなファクトリパターンの長所と短所
- 利点：
- 図1に示すように、遮蔽製品の具体的な実装は、呼び出し側は、唯一の製品のインターフェースに関する。
- 2、シンプル
- 短所：
- クローズドの原則 - 1、製品を増やし、あなたはファクトリクラスを変更する必要があり、オープンを満たしていません
- 2、責任の高い凝集配分の原則に違反するすべての論理インスタンスを作成するに焦点を当てたファクトリクラス
Factory Methodパターンの長所と短所
- 利点：
- 1、それは簡単なファクトリパターンの利点を継承します
- クローズ原則 - 2、オープンに準拠
- 短所：
- 1、ある程度システムの複雑さを増す、システムクラスのペアの数を増やすことで、その結果、新しいファクトリクラスを追加する必要があり、製品を向上させます。
Abstract Factoryパターンの長所と短所
- 利点：
- 1、顧客が作成されているかを知る必要がないように、特定のクラスの生成を分離します
- 図2に示すように、各クラスは、複数のオブジェクトによって作成することができるコンクリート工場製品ファミリは、製品ファミリは、新しいコンクリート工場製品ファミリと容易に追加するために、増加または代替的より便利です。
- 短所
- 「開閉の原則を」プレゼンテーションの傾きを新製品を追加する階層構造は非常に複雑で、サポートするために、すべての具体的なファクトリクラス抽象工場を変更する必要があります。

シンプルファクトリー：同じレベルの構造を生成するために使用される任意の製品。（新製品、主に新製品を追加するためには、単一の開口部を満たしていない責任の原則に沿ったファクトリクラスを変更する必要がある - 。原則休み）
ファクトリメソッド：製品の同じ階層構造を製造するためには、固定されています。（サポートは、新製品の既存の工場を変更する必要が任意の製品を追加していない、責任の原則に沿って、単一工場に対応した製品を向上させる必要が、オープンに沿って - 原理を閉じたが、複雑さを紹介します。）
抽象ファクトリー：すべての製品の異なる製品群を生成するために使用されます。（新製品を追加すると、植物は製品ファミリを高めるために修正する必要があり、一部はオープンに合わせて、単一責任の原則に沿って植物を増加させる必要性 - 閉じ原則として、複雑さの低減）
最後に、すべての3つのモデルは、長所と短所の工場を持っている、唯一の最も適した、何の最高はありません！