デザインパターン(3)ファクトリメソッドパターン

元のリンクを提供しますhttps://blog.csdn.net/sinat_21107433/article/details/102616501

ファクトリメソッドパターンのアイデア

シンプルなファクトリデザインパターンのアイデアは、特定の製品が追加されるたびに、ファクトリの内部製品構成を変更する必要があることを決定します。開閉の原則のため、外の世界に開いて​​、内側に閉じて、ファクトリメソッドデザインモードのアイデアは、すべての特定の製品を統一された方法で作成するために使用されるわけではありません。さまざまな工場が新しい製品を追加する必要があります新製品を追加するときは、対応する製品を追加する必要があります。ファクトリ。

ファクトリメソッドパターン:オブジェクトを作成するためのインターフェイスを定義しますが、インスタンス化するクラスをサブクラスに決定させます。ファクトリメソッドパターンは、クラスのサブクラスへのインスタンス化を遅らせます。

ファクトリメソッドパターン構造

上記のファクトリメソッドパターンの導入から、このパターンは次の主要メンバーで構成されていることがわかります。

  • Abstract Factory(AbstractFactory):特定の製品を生成するすべてのファクトリクラスの基本クラスであり、ファクトリクラスのパブリックメソッドを提供します。
  • コンクリート工場(ConcreteFactory):特定の製品を生産する
  • Abstract Product(AbstractProduct):すべての製品の基本クラスであり、製品クラスのパブリックメソッドを提供します
  • コンクリート製品(ConcreteProduct):特定の製品カテゴリ

ここに画像の説明を挿入

ファクトリメソッドパターンの例

需求
需求
需求
客户
篮球工厂
篮球
足球工厂
足球
排球工厂
排球

対応するUML図は次のとおりです:
ここに画像の説明を挿入
factorymethod.h

#include <iostream>
#include <string.h>

using namespace std;

//抽象产品类AbstractProduct
class AbstractSportProduct
{
    
    
public:
  AbstractSportProduct() {
    
    }
  //抽象方法:
  void printName(){
    
    };
  void play(){
    
    };
};

//具体产品类Basketball
class Basketball : public AbstractSportProduct
{
    
    
public:
  Basketball()
  {
    
    
    printName();
    play();
  }
  //具体实现方法
  void printName()
  {
    
    
    cout << "Get Basketball\n";
  }
  void play()
  {
    
    
    cout << "Play Basketball\n\n";
  }
};

//具体产品类Football
class Football : public AbstractSportProduct
{
    
    
public:
  Football()
  {
    
    
    printName();
    play();
  }
  //具体实现方法
  void printName()
  {
    
    
    cout << "Get Football\n";
  }
  void play()
  {
    
    
    cout << "Play Football\n\n";
  }
};

//具体产品类Volleyball
class Volleyball : public AbstractSportProduct
{
    
    
public:
  Volleyball()
  {
    
    
    printName();
    play();
  }
  //具体实现方法
  void printName()
  {
    
    
    cout << "Get Volleyball\n";
  }
  void play()
  {
    
    
    cout << "Play Volleyball\n\n";
  }
};

//抽象工厂类
class AbstractFactory
{
    
    
public:
  virtual AbstractSportProduct *getSportProduct() = 0;
};

//具体工厂类BasketballFactory
class BasketballFactory : public AbstractFactory
{
    
    
public:
  BasketballFactory()
  {
    
    
    cout << "BasketballFactory\n";
  }
  AbstractSportProduct *getSportProduct()
  {
    
    
    cout << "Basketball";
    return new Basketball();
  }
};

//具体工厂类FootballFactory
class FootballFactory : public AbstractFactory
{
    
    
public:
  FootballFactory()
  {
    
    
    cout << "FootballFactory\n";
  }
  AbstractSportProduct *getSportProduct()
  {
    
    
    cout << "Football";
    return new Football();
  }
};

//具体工厂类VolleyballFactory
class VolleyballFactory : public AbstractFactory
{
    
    
public:
  VolleyballFactory()
  {
    
    
    cout <<  "VolleyballFactory\n";
  }
  AbstractSportProduct *getSportProduct()
  {
    
    
    cout << "Valleyball";
    return new Volleyball();
  }
};

factorymethod.cpp

#include <iostream>
#include "factorymethod.h"

using namespace std;

int main()
{
    
    
	cout << "工厂方法模式\n\n";
	
	//定义工厂类对象和产品类对象
	AbstractFactory *fac = NULL;
	AbstractSportProduct *product = NULL;

	fac = new BasketballFactory();
	product = fac->getSportProduct();
	if (fac)
	{
    
    
		delete fac;
	}
	if (product) {
    
    
		delete product;
	}

	fac = new FootballFactory();
	product = fac->getSportProduct();
	if (fac)
	{
    
    
		delete fac;
	}
	if (product) {
    
    
		delete product;
	}

	fac = new VolleyballFactory();
	product = fac->getSportProduct();	
	if (fac)
	{
    
    
		delete fac;
	}
	if (product) {
    
    
		delete product;
	}

	return 0;
}

ファクトリメソッドパターンの概要

要約すると、スポーツをしたい場合は、それに応じて工場を追加する必要があることがわかります。したがって、単純なファクトリモデルと比較して、ファクトリメソッドモデルは開閉の原則に沿っています。

利点:

  1. ファクトリメソッドは、顧客が必要とする製品を作成するために使用され、同時に、インスタンス化される特定の製品カテゴリの詳細を顧客から非表示にします。ユーザーは、必要な製品に対応するファクトリのみを気にする必要があります。
  2. 作成する製品はファクトリが独自に決定し、作成プロセスは特定のファクトリオブジェクトにカプセル化されます。ポリモーフィックデザインはファクトリメソッドパターンの鍵です。
    新しい製品を追加するときに、元のコードを変更する必要がないため、システムのスケーラビリティと開発に準拠しています。原則を閉じます。

短所:

  1. 新製品を追加するときは、同時に新製品ファクトリを追加する必要があります。システム内のクラスの数がペアで増えるため、システムが複雑になります。より多くのクラスをコンパイルして実行する必要があるため、余分なオーバーヘッドが増加します。システムの;
  2. 工場と製品の両方で抽象化レイヤーが導入されています。クライアントコードで使用される抽象化レイヤー(AbstractFactoryとAbstractSportProduct)は、システムの抽象化レベルと理解の難しさを高めます。

該当する環境:

  • クライアントは、作成する必要のあるオブジェクトのクラスを知る必要はありません。
  • 抽象ファクトリクラスは、そのサブクラスを介して作成するオブジェクトを指定します(ポリモーフィックデザインとリヒター置換の原則を使用)

おすすめ

転載: blog.csdn.net/qq_24649627/article/details/115008349