デザインパターン1/23ファクトリモード

著者K_Eckel

オリジナル住所http://www.mscenter.edu.cn/blog/k_eckel

問題は
、多くの場合、オブジェクト指向システム設計の次の二つの問題に遭遇した：
1）凝集（凝集）とルーズカップリング（カップリング）、私たちはしばしば、いくつかの抽象クラス公開インターフェースを改善するための抽象ベースクラスまたはインタフェースを形成するために。このように、我々は、実装され、実際の基底クラスのサブクラスを指す多型の目的を達成するためのポインタを宣言することができます。コード;サブクラスのn個の数が抽象基本クラスから継承するためにここに一つの問題が発生しやすいです、我々は、このような新しい×××の準備の各サブクラスを配置するために使用する必要がありました。

ここでは、2つの問題

1）クライアントのプログラマは、可能な名前の競合に対処するために、いくつかの名前は非常に読み取れない場合があり、システムが複雑な場合、問題を命名することは非常にひどい仕打ちだろう（実際のサブクラスの名前を知っている必要がありますし、メモラビリティ、別のプログラマーの脇奇妙な個人的な好み。）、

2）膨張やメンテナンスプログラムはますます困難になってきています。

2）別のケースは、具体的なサブクラスをインスタンス化するかを正確に把握していない親クラスです。ここでの意味は次のとおりです。BはBのサブクラスをインスタンス化することを知っているが、DのクラスAのサブクラスではありません、特にAに、抽象親クラスで、私たちはクラスBへのクラスAで使用したいとしますそれは知っています。Aでは、我々は、はい×××かわからないので、直接、新しい×××な文を使用する方法がありません。
二つの問題には2点の以上のリードは、Factoryパターン最も重要な機能になります。
;オブジェクト1）インタフェースの定義、パッケージオブジェクトの作成作成
2）、このような具体的な作業は、クラスのサブクラスを遅らせることを。

モードの選択
我々は通常、上記の二つの問題を解決するためのファクトリモードを使用します。最初の問題で、私たちはしばしばインターフェースを宣言したオブジェクトを作成し、オブジェクトを作成するプロセスをカプセル化します。ここでの工場は、本当の意味での工場（生産目標）に似ています。（サブクラスだけで終わりでインスタンス化するクラスを決めるために）2つ目の質問では、我々は、オブジェクトのインタフェースを提供するオブジェクトを作成する必要があり、サブクラスで特定の実装を提供します。
最初の場合の工場概略の構成は以下のとおりです。

図1：工場モードの構造図

（それは他の手段を通じて、この問題を解決することができますので）図1は、それほど頻繁にシステム開発に使用されるが、これは最大の力ではありませんFactoryパターンは、ファクトリーモードに位置しています。工場モデルは遅延（第2の問題）のサブクラスの最も重要な例であるオブジェクトを作成するためのインタフェースを提供するだけでなく、次の場合は、工場の概略図です。

図2：工場モードの構造図

図2のアプリケーションキーモードの工場だけでパッケージオブジェクトを作成することはありませんが、実装サブクラスのオブジェクトを作成する必要があります。工場だけで実際には、今のサブ工場で、インタフェースオブジェクトの作成を提供中ConcreteFactoryはクラスで行いました。これは、2と1の嘘との違いです。

達成
完全なコード例（コード）を
工場出荷時のモデルは比較的簡単です達成するために、ここでの学習とリファレンス初心者の便宜のために、完全な実装コード（6.0の下で実行されるすべてのC ++実装を使用してコード、およびVCテスト）を与えます。

代码片断1：Product.h
//Product.h
#ifndef _PRODUCT_H_
#define _PRODUCT_H_

class Product
{
public:
	virtual ~Product() = 0;
	protected:
	Product();
private:
};

class ConcreteProduct:public Product
{
public:
	~ConcreteProduct();
	ConcreteProduct();
protected:
private:
};

#endif //~_PRODUCT_H_

代码片断2：Product.cpp
//Product.cpp
#include "Product.h"
#include <iostream>
using namespace std;

Product::Product()
{
}

Product::~Product()
{
}

ConcreteProduct::ConcreteProduct()
{
	cout<<"ConcreteProduct...."<<endl;
}

ConcreteProduct::~ConcreteProduct()
{
}

代码片断3：Factory.h
//Factory.h
#ifndef _FACTORY_H_
#define _FACTORY_H_
class Product;

class Factory
{
public:
	virtual ~Factory() = 0;
	virtual Product* CreateProduct() = 0;
	protected:
	Factory();
private:
};

class ConcreteFactory:public Factory
{
public:
	~ConcreteFactory();
	ConcreteFactory();
	Product* CreateProduct();
protected:
private:
};

#endif //~_FACTORY_H_

代码片断4： Factory.cpp
//Factory.cpp
#include "Factory.h"
#include "Product.h"
#include <iostream>
using namespace std;

Factory::Factory()
{
}

Factory::~Factory()
{
}

ConcreteFactory::ConcreteFactory()
{
	cout<<"ConcreteFactory....."<<endl;
}

ConcreteFactory::~ConcreteFactory()
{
}

Product* ConcreteFactory::CreateProduct()
{
	return new ConcreteProduct();
}

代码片断5：main.cpp
//main.cpp
#include "Factory.h"
#include "Product.h"
#include <iostream>
using namespace std;

int main(int argc,char* argv[])
{
	Factory* fac = new ConcreteFactory();
	Product* p = fac->CreateProduct();
	return 0;
}

符号の説明
例えば作成を作成し、対応するFactoryによって取り付けることができるオブジェクトを作成するためのインタフェースを提供する問題に関しては、所与のサンプルコードは、親クラス溶液工場パターンをインスタンス化するために、特定のどの特定のサブクラスの問題を知りませんで***製品（）することができます。詳細については、議論に参加してください。

話題
実際の開発でファクトリモードが広く使用されている、オブジェクト指向システムは、多くの場合、オブジェクト作成の問題に直面している：多すぎるクラスを作成します。そして、インタフェースパッケージ（最初の関数）は、オブジェクトの工場が提供作成し、それは部分的に本当の問題を解決しているクラスのサブクラスのインスタンス化（第2機能）に延期します。単純な例では、Iは、モデル系の可読性ファクトリーを使用して、このようにプロセスを非常に大きなオブジェクトを作成し、原因文法ベースの処理における各非終端記号のための構成に、オープンシステムVisualCMCSを開発した意味解析手順でありますエレガントかつメンテナンスが多くなっています。

ファクトリモードは、少なくとも次の二つの質問をもたらします：

関数本体のConcreteProductそれぞれ特定のクラスのインスタンスは、その後、私たちはこの新しいConcreteProductに対処するには、システム上のメソッドを追加する必要があります場合は1）、この工場インターフェイスは常に）クローズ（閉鎖することを拒否することができます。もちろん、我々は多状態を介してこれを達成するために、サブクラスのファクトリーを作成することができますが、それはコストとして新しいクラスを作成することもあります。

2）実装では、我々は、つまり、FactoryMethodに（）パラメータの化学的方法によって、パラメータは実際には（もちょうどそれを）やってVisualCMCSで作者を特定の製品を作成を正確に決定するために使用されて渡すことができます。もちろん、テンプレートパラメータとして特定のProductクラスになることですサブクラスを作成するサブクラス1）をテンプレート化することで回避することができ、また、実装が非常に簡単です。

図から分かるように、オブジェクトを作成するFactoryパターンは、開発者に良い実装戦略を与えるが、クラスに限定Factoryパターン、私たちがしたい場合は、（製品は、共通の基本クラスを持っている、あるクラスです）クラスの異なるクラスは、AbstractFactoryを使用し、作成したインタフェースオブジェクトを提供します。

ます。https：//www.cnblogs.com/caleb/archive/2011/09/07/2169486.htmlで再現

デザインパターン1/23ファクトリモード

おすすめ