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