Creation Model-Abstract Factory Pattern

The factory method pattern solves the problem of too heavy responsibilities of the factory class in the simple factory pattern by introducing the factory hierarchy. However, because each factory in the factory method pattern only produces one type of product, it may cause a large number of factory classes in the system. It is bound to increase the overhead of the system. At this point, we can consider combining some related products into a "product family, which is produced by the same factory. This is the basic idea of ​​the abstract factory pattern we will learn in this article. The
sdfs
                "factory method pattern" realizes multi-regional fruit class diagrams.
1. When we want to add a new product, such as grapes, although there is no need to modify the code, we need to add a large number of classes, and also need to add relative factories. (system overhead, maintenance cost)
2. If we use the same region Fruits (Japan, Japan, Japan), then we need to create specific factories separately. If the selection is wrong, it will cause confusion. Although some constraints can be added, the code implementation becomes complicated.

Roles and responsibilities in the model

Insert picture description here
Abstract Factory (Abstract Factory) role: It declares a set of methods used to create a family of products, each method corresponds to a product.
Concrete Factory (Concrete Factory) role: It implements the method of creating products declared in the abstract factory, and generates a set of concrete products. These products constitute a product family, and each product is located in a certain product hierarchy.
Abstract Product (Abstract Product) role: It declares an interface for each product, and declares the business methods of the product in the abstract product.
Concrete Product (Concrete Product) role: It defines the concrete product objects produced by the concrete factory and implements the business methods declared in the abstract product interface.

Abstract factory pattern case

Insert picture description here

#define _CRT_SECURE_NO_WARNINGS
#include<iostream>
using namespace std;

//抽象苹果类
class AbstractApple 
{
    
    
public:
	virtual void showName() = 0;
};

//抽象香蕉
class AbstractBanana 
{
    
    
public:
	virtual void showName() = 0;
};

//抽象鸭梨
class AbstractPear 
{
    
    
public:
	virtual void showName() = 0;
};

//中国苹果
class ChineseApple : public AbstractApple 
{
    
    
public:
	virtual void showName() 
	{
    
    
		cout << "中国苹果" << endl;
	}
};

//美国苹果
class AmericanApple : public AbstractApple 
{
    
    
public:
	virtual void showName() 
	{
    
    
		cout << "美国苹果" << endl;
	}
};

//日本苹果
class JapaneseApple : public AbstractApple 
{
    
    
public:
	virtual void showName() 
	{
    
    
		cout << "日本苹果" << endl;
	}
};

//中国香蕉
class ChineseBanana : public AbstractBanana 
{
    
    
public:
	virtual void showName() 
	{
    
    
		cout << "中国香蕉" << endl;
	}
};

//美国香蕉
class AmericanBanana : public AbstractBanana 
{
    
    
public:
	virtual void showName() 
	{
    
    
		cout << "美国香蕉" << endl;
	}
};

//日本香蕉
class JapaneseBanana : public AbstractBanana
{
    
    
public:
	virtual void showName()
	{
    
    
		cout << "日本香蕉" << endl;
	}
};

//中国鸭梨
class ChinesePear : public AbstractPear 
{
    
    
public:
	virtual void showName() {
    
    

		cout << "中国鸭梨" << endl;
	}
};

//美国鸭梨
class AmericanPear : public AbstractPear 
{
    
    
public:
	virtual void showName() 
	{
    
    
		cout << "美国鸭梨" << endl;
	}
};

//日本鸭梨
class JapanesePear : public AbstractPear 
{
    
    
public:
	virtual void showName() 
	{
    
    
		cout << "日本鸭梨" << endl;
	}
};

//抽象工厂
class AbstractFactory 
{
    
    
public:
	virtual AbstractApple* CreateApple() = 0;
	virtual AbstractBanana* CreateBanana() = 0;
	virtual AbstractPear* CreatePear() = 0;
};

//中国工厂
class ChineseFactory : public AbstractFactory 
{
    
    
public:
	virtual AbstractApple* CreateApple() 
	{
    
    
		return new ChineseApple;
	}
	virtual AbstractBanana* CreateBanana() 
	{
    
    
		return new ChineseBanana;
	}
	virtual AbstractPear* CreatePear() 
	{
    
    
		return new ChinesePear;
	}
};

//美国工厂
class AmericanFactory : public AbstractFactory
{
    
    
public:
	virtual AbstractApple* CreateApple() 
	{
    
    
		return new AmericanApple;
	}
	virtual AbstractBanana* CreateBanana() 
	{
    
    
		return new AmericanBanana;
	}
	virtual AbstractPear* CreatePear() 
	{
    
    
		return new AmericanPear;
	}
};

//美国工厂
class JapaneseFactory : public AbstractFactory 
{
    
    
public:
	virtual AbstractApple* CreateApple() 
	{
    
    
		return new JapaneseApple;
	}
	virtual AbstractBanana* CreateBanana() 
	{
    
    
		return new JapaneseBanana;
	}
	virtual AbstractPear* CreatePear() 
	{
    
    
		return new JapanesePear;
	}
};


void test01() 
{
    
    

	AbstractFactory* factory = NULL;
	AbstractApple* apple = NULL;
	AbstractBanana* banana = NULL;
	AbstractPear* pear = NULL;

	factory = new ChineseFactory; //创建中国工厂
	apple = factory->CreateApple();
	banana = factory->CreateBanana();
	pear = factory->CreatePear();

	apple->showName();
	banana->showName();
	pear->showName();

	delete pear;
	delete banana;
	delete apple;
	delete factory;

	factory = new AmericanFactory; //创建美国工厂
	apple = factory->CreateApple();
	banana = factory->CreateBanana();
	pear = factory->CreatePear();

	apple->showName();
	banana->showName();
	pear->showName();

	delete pear;
	delete banana;
	delete apple;
	delete factory;

	factory = new JapaneseFactory; //创建日本工厂
	apple = factory->CreateApple();
	banana = factory->CreateBanana();
	pear = factory->CreatePear();

	apple->showName();
	banana->showName();
	pear->showName();

	delete pear;
	delete banana;
	delete apple;
	delete factory;

}

int main() 
{
    
    

	test01();


	system("pause");
	return EXIT_SUCCESS;
}

Advantages and disadvantages of abstract factory pattern

Advantages:
(1) Have the advantages of the factory method pattern
(2) When multiple objects in a product family are designed to work together, it can ensure that the client always uses only the objects in the same product family.
(3) It is very convenient to add a new product family, without modifying the existing system, conforming to the "opening and closing principle".

Disadvantages: It
is troublesome to add a new product level structure, requiring major modifications to the original system, and even the need to modify the abstract layer code, which obviously brings greater inconvenience and violates the "open and close principle".

Applicable scene

(1) There is more than one product family in the system. And only one product family is used each time. The user can dynamically change the product family through configuration files and other methods, and can also easily add new product families.
(2) The product grade structure is stable. After the design is completed, no new product level structure will be added to the system or the existing product level structure will not be deleted.

Guess you like

Origin blog.csdn.net/bureau123/article/details/112983920