設計モードのC++実現3.ちゅうしょうこうじょう
単純なファクトリモデルとファクトリモデルでは、同じタイプの製品サブクラスに共通の方法が必要であり、製品サブクラスの拡張を制限します.抽象ファクトリは、クライアントが製品を指定する必要がなく、複数の製品ファミリー内の製品オブジェクトを作成するインタフェースをクライアントに提供します.抽象ファクトリでは、同じクラスの製品サブクラスを1つのクラスに分類し、同じ抽象サブクラスを継承させ、1つの抽象サブクラスの具体的な製品サブクラスを1つのグループと見なします.プロダクトファミリーとは、異なるプロダクト階層に位置し、機能に関連付けられたプロダクトからなるファミリーを指します.一般に、異なる階層構造の同じ位置に位置する.各プロダクトファミリーのプロダクト数は、プロダクト階層の数と同じです.ユーザは工場およびファミリーによって判断する
ユーザーが使用する場合、どの工場とどの製品ファミリーの製品クラス、すなわちグループとファミリーの2次元座標によって特定の製品サブクラスを決定するかを知る必要があります.各工場のサブクラスはファミリー製品を担当し、1つのタイプの製品を生成する方法があります.
例を挙げて説明する.抽象ファクトリベースクラスAbstractFactoryに対して3つの具体的なファクトリクラスFactory 1,Factory 2,Factory 3が派生した場合,ファミリー数は3,すなわち抽象製品クラスごとに3つの具体的なサブクラスがある.2つの抽象プロダクトクラスAbstractProductA、AbstractProductB、すなわち2つのグループがある場合、ファクトリクラスにはオブジェクトを作成する関数createProductA、createProductBが2つあります.
シンプルな実装:
抽象ファクトリの用途は,元の意味はUNIXとWindowsのためであり,両者の多くの操作は同じである.これらの同じオブジェクトはFile,Buttonなどであり,これらはそれぞれWindows族とUnix族に1部ずつあり,FileのようなオブジェクトのファクトリクラスはUnixfileとWindowsfileを1組として構造化されている.
抽象工場は異なるタイプの製品をサポートし、同じ一族の間の異なるタイプの製品をより便利に使用する.ファミリー製品を追加する場合、工場類と製品類のインタフェースを修正せず、開閉原則に背かない.
欠点:構造が肥大化しすぎて、私が簡単に実現しても、3 x 2は、以上のコードを書いています.製品グループ数が多くなったり、ファミリー数が増えたりすると、管理が難しくなります.製品のセットを追加するたびに、工場クラスと製品クラスのインタフェースが修正され、開閉原則に違反します.
ユーザーが使用する場合、どの工場とどの製品ファミリーの製品クラス、すなわちグループとファミリーの2次元座標によって特定の製品サブクラスを決定するかを知る必要があります.各工場のサブクラスはファミリー製品を担当し、1つのタイプの製品を生成する方法があります.
例を挙げて説明する.抽象ファクトリベースクラスAbstractFactoryに対して3つの具体的なファクトリクラスFactory 1,Factory 2,Factory 3が派生した場合,ファミリー数は3,すなわち抽象製品クラスごとに3つの具体的なサブクラスがある.2つの抽象プロダクトクラスAbstractProductA、AbstractProductB、すなわち2つのグループがある場合、ファクトリクラスにはオブジェクトを作成する関数createProductA、createProductBが2つあります.
シンプルな実装:
class AbstractProductA{
public:
virtual void fun() = 0;
AbstractProductA(){}
virtual ~AbstractProductA(){}
};
class ProductA_1 : public AbstractProductA{
public:
virtual void fun(){cout<< "A_1"<<endl;}
ProductA_1(){}
virtual ~ProductA_1(){}
};
class ProductA_2 : public AbstractProductA{
public:
virtual void fun(){cout<< "A_2"<<endl;}
ProductA_2(){}
virtual ~ProductA_2(){}
};
class ProductA_3 : public AbstractProductA{
public:
virtual void fun(){cout<< "A_3"<<endl;}
ProductA_3(){}
virtual ~ProductA_3(){}
};
//B
class AbstractProductB{
public:
virtual void fun() = 0;
AbstractProductB(){}
virtual ~AbstractProductB(){}
};
class ProductB_1 : public AbstractProductB{
public:
virtual void fun(){cout<< "B_1"<<endl;}
ProductB_1(){}
virtual ~ProductB_1(){}
};
class ProductB_2 : public AbstractProductB{
public:
virtual void fun(){cout<< "B_2"<<endl;}
ProductB_2(){}
virtual ~ProductB_2(){}
};
class ProductB_3 : public AbstractProductB{
public:
virtual void fun(){cout<< "B_3"<<endl;}
ProductB_3(){}
virtual ~ProductB_3(){}
};
class AbstractFactory{
public:
AbstractFactory(){};
virtual ~AbstractFactory();
virtual AbstractProductA* createProductA() = 0;
virtual AbstractProductB* createProductB() = 0;
};
class Factory1:public AbstractFactory{
public:
Factory1(){}
~Factory1(){}
AbstractProductA* createProductA(){return new ProductA_1();}
AbstractProductB* createProductB(){return new ProductB_1();}
};
class Factory2:public AbstractFactory{
public:
Factory2(){}
~Factory2(){}
AbstractProductA* createProductA(){return new ProductA_2();}
AbstractProductB* createProductB(){return new ProductB_2();}
};
class Factory3:public AbstractFactory{
public:
Factory3(){}
~Factory3(){}
AbstractProductA* createProductA(){return new ProductA_3();}
AbstractProductB* createProductB(){return new ProductB_3();}
};
抽象ファクトリの用途は,元の意味はUNIXとWindowsのためであり,両者の多くの操作は同じである.これらの同じオブジェクトはFile,Buttonなどであり,これらはそれぞれWindows族とUnix族に1部ずつあり,FileのようなオブジェクトのファクトリクラスはUnixfileとWindowsfileを1組として構造化されている.
抽象工場は異なるタイプの製品をサポートし、同じ一族の間の異なるタイプの製品をより便利に使用する.ファミリー製品を追加する場合、工場類と製品類のインタフェースを修正せず、開閉原則に背かない.
欠点:構造が肥大化しすぎて、私が簡単に実現しても、3 x 2は、以上のコードを書いています.製品グループ数が多くなったり、ファミリー数が増えたりすると、管理が難しくなります.製品のセットを追加するたびに、工場クラスと製品クラスのインタフェースが修正され、開閉原則に違反します.