简单工厂（Simple Factory）模式
我们从实际例子出发，来看在什么情况下，应用简单工厂模式。
还是以一个游戏举例
//策划：亡灵类怪物，元素类怪物，机械类怪物：都有生命值，魔法值，攻击力三个属性。
//Monster作为父类，M_Undead（亡灵类），M_Element（元素类怪物），M_Mechanic（机械类怪物）。
一般写法如下：
#include
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, i服务器托管nt attack) :Monster(life, magic, attack) {
cout 问题
那么这个不使用工厂模式的一般写法有啥问题呢？或者说有啥缺点呢？
//假设我们在每一个关卡都要 new 出来这些实例对象。
//有一天策划找到我们说，机械怪物的生命力要加1,我们能想到的合适的办法是：
//将怪物的参数做成配置文件，游戏加载时候就将配置文件读取成一个一个的全局变量，然后new 的时候用这些全局变量
//有一天策划又找到我们说：怪物还应该有个”盔甲”,”鞋子”,”帽子”,”武器”,”盾牌”这些属性，
//那我们就要改动构造方法了，这个不改不行了，又因为我们在每一关都要new出来这些怪物，因此每个关卡的代码都要改动。
//言外之意是：这种普通的写法 new +具体类名来创建对象是一种 依赖具体类型的紧耦合关系
解决方案
那么怎么改动才合理呢？引入简单工厂模式
//工厂模式：通过把创建对象的代码包装起来，做到创建对象的代码与具体的业务逻辑代码相隔离的目的。
#include
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 c:usersadministratorsourcereposdesignpattern02simplefactory02simplefactory.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 遗留问题
//从上面的代码可以看到，简单工厂模式确实实现了new 出来具体对象， 和 业务逻辑的分离，
//但是不符合 “开闭原则”
//”开闭原则”说的是代码扩展性问题——对扩展开放，对修改关闭（封闭）；
//假设过了两天，策划找到我们说：加一种怪物，新怪物类型：M_Beast（野兽类）
//那我们要怎么改呢？首先肯定是加一个 M_Beast类了，继承Monster
//然后MonsterFactory 中改动 createMonster方法完成。
//很显然，我们要改动到原先的 createMonster 方法，这是违反了 “开闭原则的”。
//那么如何改动才合理呢？这就要用到 “工厂方法” 模式
简单工厂的UML 图
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
上周停去准备计算机服务器托管网三级的考试啦，在考场上看到题目就知道这次稳了！只有一周的时间，背熟笔记，也能稳稳考过计算机三级网络技术！ 服务器托管网 服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net相关推荐: RabbitMQ …
