简单工厂(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 图