设计模式笔记-xx工厂模式

一， 简单工厂模式

主要特点是需要在工厂类中用多个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就行了！这里的各个依赖关系要清楚

代码和其它工厂模式差不多，略！关键要搞清楚应用场景！