简单工厂(Simple Factory)模式
我们从实际例子出发,来看在什么情况下,应用简单工厂模式。
还是以一个游戏举例
//策划:亡灵类怪物,元素类怪物,机械类怪物:都有生命值,魔法值,攻击力三个属性。
//Monster作为父类,M_Undead(亡灵类),M_Element(元素类怪物),M_Mechanic(机械类怪物)。
一般写法如下:
#include <iostream>
using namespace std;//(1)简单工厂(Simple Factory)模式
//策划:亡灵类怪物,元素类怪物,机械类怪物:都有生命值,魔法值,攻击力三个属性。
//Monster作为父类,M_Undead(亡灵类),M_Element(元素类怪物),M_Mechanic(机械类怪物)。namespace _namespace1 {class Monster {public:Monster(int life, int magic, int attack) : m_life(life), m_magic(magic), m_attack(attack){};virtual ~Monster() {};protected:int m_life;int m_magic;int m_attack;};//M_Undead(亡灵类)class M_Undead :public Monster {public:M_Undead(int life, int magic, int attack) :Monster(life, magic, attack) {cout << "创建了一个亡灵类 life = " << m_life <<" magic = "<< m_magic << " attack = "<< m_attack << endl;}};//M_Element(元素类怪物)class M_Element :public Monster {public:M_Element(int life, int magic, int attack) :Monster(life, magic, attack) {cout << "创建了一个元素类怪物 life = " << m_life << " magic = " << m_magic << " attack = " << m_attack << endl;}};//M_Mechanic(机械类怪物)class M_Mechanic :public Monster {public:M_Mechanic(int life, int magic, int attack) :Monster(life, magic, attack) {cout << "创建了一个机械类怪物 life = " << m_life << " magic = " << m_magic << " attack = " << m_attack << endl;}};};void normalTest() {_namespace1::Monster *pm1 = new _namespace1::M_Undead(1, 2, 3);_namespace1::Monster *pm2 = new _namespace1::M_Element(4, 5, 6);_namespace1::Monster *pm3 = new _namespace1::M_Mechanic(7, 8, 9);delete pm1;delete pm2;delete pm3;}int main()
{_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);//程序退出时检测内存泄漏并显示到“输出”窗口//不使用工厂模式的一般写法normalTest();std::cout << "Hello World!\n";
}
问题
那么这个不使用工厂模式的一般写法有啥问题呢?或者说有啥缺点呢?
//假设我们在每一个关卡都要 new 出来这些实例对象。
//有一天策划找到我们说,机械怪物的生命力要加1,我们能想到的合适的办法是:
//将怪物的参数做成配置文件,游戏加载时候就将配置文件读取成一个一个的全局变量,然后new 的时候用这些全局变量
//有一天策划又找到我们说:怪物还应该有个"盔甲","鞋子","帽子","武器","盾牌"这些属性,
//那我们就要改动构造方法了,这个不改不行了,又因为我们在每一关都要new出来这些怪物,因此每个关卡的代码都要改动。
//言外之意是:这种普通的写法 new +具体类名来创建对象是一种 依赖具体类型的紧耦合关系
解决方案
那么怎么改动才合理呢?引入简单工厂模式
//工厂模式:通过把创建对象的代码包装起来,做到创建对象的代码与具体的业务逻辑代码相隔离的目的。
#include <iostream>
using namespace std;//(1)简单工厂(Simple Factory)模式
//策划:亡灵类怪物,元素类怪物,机械类怪物:都有生命值,魔法值,攻击力三个属性。
//Monster作为父类,M_Undead(亡灵类),M_Element(元素类怪物),M_Mechanic(机械类怪物)。namespace _namespace1 {class Monster {public:Monster(int life, int magic, int attack) : m_life(life), m_magic(magic), m_attack(attack){};virtual ~Monster() {};protected:int m_life;int m_magic;int m_attack;};//M_Undead(亡灵类)class M_Undead :public Monster {public:M_Undead(int life, int magic, int attack) :Monster(life, magic, attack) {cout << "创建了一个亡灵类 life = " << m_life <<" magic = "<< m_magic << " attack = "<< m_attack << endl;}};//M_Element(元素类怪物)class M_Element :public Monster {public:M_Element(int life, int magic, int attack) :Monster(life, magic, attack) {cout << "创建了一个元素类怪物 life = " << m_life << " magic = " << m_magic << " attack = " << m_attack << endl;}};//M_Mechanic(机械类怪物)class M_Mechanic :public Monster {public:M_Mechanic(int life, int magic, int attack) :Monster(life, magic, attack) {cout << "创建了一个机械类怪物 life = " << m_life << " magic = " << m_magic << " attack = " << m_attack << endl;}};const int UndeadType = 1;const int ElementType = 2;const int MechanicType = 3;//简单工厂模式,怪物工厂class MonsterFactory {public:Monster * createMonster(int monstertype) {Monster * tempPM = nullptr;switch (monstertype){case UndeadType://UndeadType,ElementType,MechanicType都是程序员定义的表示怪物类型的值//1,2,3可以来源于从配置文件读取的值,//我们可以将 new M_Undead的代码全部都写在这里,//如果策划要改动构造方法,给构造方法里面加上"盔甲","鞋子","帽子","武器","盾牌"这些属性//我们只需要在这里改动,无需在业务逻辑层面改动构造方法。tempPM = new M_Undead(11, 22, 33);break;case ElementType:tempPM = new M_Element(44,55,66);//提示:如果元素怪物有额外的属性,或者参数,也可以在这里设置//tempPM.setxxx(xxx);break;case MechanicType:tempPM = new M_Mechanic(77,88,99);break;default:return tempPM;break;}//注意switch case 使用时候的 这个warning 提示:3 > c:\users\administrator\source\repos\designpattern\002simplefactory\002simplefactory.cpp(80) : warning C4715 : “_namespace1::MonsterFactory::createMonster” : 不是所有的控件路径都返回值//解决方案是加上如下的这一样return tempPM;}};
};void normalTest() {_namespace1::Monster *pm1 = new _namespace1::M_Undead(1, 2, 3);_namespace1::Monster *pm2 = new _namespace1::M_Element(4, 5, 6);_namespace1::Monster *pm3 = new _namespace1::M_Mechanic(7, 8, 9);delete pm1;delete pm2;delete pm3;}void simpleFactoryTest() {_namespace1::MonsterFactory monsfactory;_namespace1::Monster *pm4 = monsfactory.createMonster(_namespace1::UndeadType);_namespace1::Monster *pm5 = monsfactory.createMonster(_namespace1::ElementType);_namespace1::Monster *pm6 = monsfactory.createMonster(_namespace1::MechanicType);delete pm4;delete pm5;delete pm6;
}int main()
{_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);//程序退出时检测内存泄漏并显示到“输出”窗口//不使用工厂模式的一般写法normalTest();//那么这个不使用工厂模式的一般写法有啥问题呢?//或者说有啥缺点呢?//假设我们在每一个关卡都要 new 出来这些实例对象。//有一天策划找到我们说,机械怪物的生命力要加1,我们能想到的合适的办法是://将怪物的参数做成配置文件,游戏加载时候就将配置文件读取成一个一个的全局变量,然后new 的时候用这些全局变量//有一天策划又找到我们说:怪物还应该有个"盔甲","鞋子","帽子","武器","盾牌"这些属性,//那我们就要改动构造方法了,这个不改不行了,又因为我们在每一关都要new出来这些怪物,因此每个关卡的代码都要改动。//言外之意是:这种普通的写法 new +具体类名来创建对象是一种 依赖具体类型的紧耦合关系//那么怎么改动才合理呢?引入简单工厂模式//工厂模式:通过把创建对象的代码包装起来,做到创建对象的代码与具体的业务逻辑代码相隔离的目的。simpleFactoryTest();//从上面的代码可以看到,简单工厂模式确实实现了new 出来具体对象, 和 业务逻辑的分离,//但是不符合 "开闭原则"//"开闭原则"说的是代码扩展性问题——对扩展开放,对修改关闭(封闭);//假设过了两天,策划找到我们说:加一种怪物,新怪物类型:M_Beast(野兽类)//那我们要怎么改呢?首先肯定是加一个 M_Beast类了,继承Monster//然后MonsterFactory 中改动 createMonster方法完成。//很显然,我们要改动到原先的 createMonster 方法,这是违反了 "开闭原则的"。//那么如何改动才合理呢?这就要用到 "工厂方法" 模式std::cout << "Hello World!\n";
}
遗留问题
//从上面的代码可以看到,简单工厂模式确实实现了new 出来具体对象, 和 业务逻辑的分离,
//但是不符合 "开闭原则"
//"开闭原则"说的是代码扩展性问题——对扩展开放,对修改关闭(封闭);
//假设过了两天,策划找到我们说:加一种怪物,新怪物类型:M_Beast(野兽类)
//那我们要怎么改呢?首先肯定是加一个 M_Beast类了,继承Monster
//然后MonsterFactory 中改动 createMonster方法完成。
//很显然,我们要改动到原先的 createMonster 方法,这是违反了 "开闭原则的"。
//那么如何改动才合理呢?这就要用到 "工厂方法" 模式
简单工厂的UML 图