一, 简单工厂模式
主要特点是需要在工厂类中用多个case分支做判断,根据传递进来的参数创造相应的产品。当增加新的产品时,当然也得修改工厂类,就是在其中
添加case分支。在平时开发的小项目里,由于对象类型单一、个数基本确定,所以基本采用这种方法来实现!并且它会和单例模式放在一起,比如我项目中就采用下面的方法:
class OPTSOLVER_API CGasElementFactory
{
public:
~CGasElementFactory();
virtual LPVOID CreateElement( IN DWORD nID, IN tstring strName, IN PIPELINE_ELEMENT_TYPE emType );
virtual VOID Free();
protected:
CGasElementFactory();
CGasElementFactory & operator = (const CGasElementFactory &);
public:
static CGasElementFactory& GetInstance();
};
client在使用该类的时候,采用下面的方法:
lpElement = ( CPipelineElement* ) CGasElementFactory::GetInstance().CreateElement( nUniqueID, strName, emType );
因此,创建对象的new操作在工厂里,delete操作在client里!其UML图较简单:
二, 工厂方法模式
上面说的简单工厂模式,每次添加一个产品子类都必须在工厂类中添加一个判断分支,这违背了开放-封闭原则。我们可以
考虑把这些判断都生成一个工厂子类,这样,每次添加产品子类的时候,只需再添加一个工厂子类就可以了。说到这读者可能就会
感觉到,如果产品子类多了,相应要添加的工厂子类也就增多。所以这种模式,只为了开放-封闭的好处,增加了复杂性,就一般的
项目来说,我感觉不是很有必要,也可能因为我还没达到那个层次!UML图如下:
代码类就不写了,在client中的使用方法如下:
AbstractFactory* factory = new FactoryA();
AbstractProduct* product = factory->createProduct();
product->operation();
delete product;
product = NULL;
delete factory;
factory = NULL;
三, 抽象工厂模式
工厂模式和简单工厂模式要求产品子类必须是同一类型的,拥有共同的方法,限制了产品子类的扩展。抽象工厂模式正是为了解决这一问题,它将同一类的产品子类归为一类,让他们继承同一个抽象类。目的就是为了创建一组相关或相互依赖的对象!
其实开始我也不明白,就是为了创建ProductA和ProductB,为什么非要分2个厂呢?一个厂可以搞定啊!假设这样的情况,某个游戏,里面有很多类型的怪物,这里好比ProductA和ProductB。为了增加趣味性,要设置难度,初级、中级、高级等,在各个级别中,这些怪物是一样的,只是难度属性不同,也就是这里的Factory1和Factory2在加工怪物时的差别!游戏难度就相当于这里的工厂,当游戏难度变化了,只需要修改Factory就行了!这里的各个依赖关系要清楚
代码和其它工厂模式差不多,略!关键要搞清楚应用场景!