批注:C++设计模式——工厂方法模式:合并

http://www.jellythink.com/archives/62

归并聚合到一个factory 中的new ProductA,B,C 新建多个分厂，有分厂创建和实现，由总厂设计。在main中直接调用分厂.

和简单工厂比较是子厂create productA,B，子厂调用

总厂将create productA,B实现，下放到各个子厂。只留设计科在总厂.设计科要求,生产Product类型的对象.多少个子厂生产和具。过去是在总厂 create productA,B;体show的内容，子厂负责.  
和简单工厂比较增加了子厂的new class factoryA,B.

advance: 1 和简单工厂比较

create ProductC. only need add FactoryC. don;t need modify Factory; don;t have multipex code with ProductA,B.

so FactoryC can stand alone test
松耦合:可扩展性好.类似CascadeBase 定义pure virtual function. ResoureMgr ,TaMgr 实现-------find 

2 和在main中比较.

main的实现是new ProductA,B。 现在是用new factoryA,B. 

QA：如果说factoryA,B分开可以变成ResourceMgr, TaMgr分开开发，那么ProductA,B 也可以啊?合并在ProductA,B上多加一层factory呢.直接用多态各组实现即可。

类似的CascadeBase中 ResourceMgr, TaMgr直接多态实现它的vitural signalhandler,没有在包一层用这个工厂方法模式.也就是说这个模式有什么用.比直接多态就可以

实现了。答案是在抽象工厂中做生产线扩展的时候就不同了,子厂有多个生产线在main中被调用.不同于直接多态.这些生产线分别归两个子厂管理.不是分散的是分厂(分类）归并的.

问题描述

之前讲到了C++设计模式——简单工厂模式，由于简单工厂模式的局限性，比如：工厂现在能生产ProductA、ProductB和ProductC三种产品了，此时，需要增加生产ProductD产品；那么，首先是不是需要在产品枚举类型中添加新的产品类型标识，然后，修改Factory类中的switch结构代码。是的，这种对代码的修改，对原有代码的改动量较大，易产生编码上的错误（虽然很简单，如果工程大了，出错也是在所难免的！！！）。这种对代码的修改是最原始，最野蛮的修改，本质上不能称之为对代码的扩展。同时，由于对已经存在的函数进行了修改，那么以前进行过的测试，都将是无效的，所有的测试，都将需要重新进行，所有的代码都需要进行重新覆盖。这种，增加成本，不能提高效率的事情，在公司是绝对不允许的（除非昏庸的PM）。出于种种原因，简单工厂模式，在实际项目中使用的较少。那么该怎么办？怎么办呢？需要对原有代码影响降到最小，同时能对原有功能进行扩展。

UML类图

那么今天介绍的工厂方法模式，就隆重登场了。它只是对简单工厂模式的扩展，在GOF的介绍中，它们是合并在一起的，而我则是单独分开进行讲解的，就是为了区分二者的利弊，便于大家在实际项目中进行更好的把握与应用。工厂方法模式是在简单工厂模式的基础上，对“工厂”添加了一个抽象层。将工厂共同的动作抽象出来，作为抽象类，而具体的行为由子类本身去实现，让子类去决定生产什么样的产品。

如图，FactoryA专心负责生产ProductA，FactoryB专心负责生产ProductB，FactoryA和FactoryB之间没有关系；如果到了后期，如果需要生产ProductC时，我们则可以创建一个FactoryC工厂类，该类专心负责生产ProductC类产品。由于FactoryA、FactoryB和FactoryC之间没有关系，当加入FactoryC加入时，对FactoryA和FactoryB的工作没有产生任何影响，那么对代码进行测试时，只需要单独对FactoryC和ProductC进行单元测试，而FactoryA和FactoryB则不用进行测试，则可省去大量无趣无味的测试工作。

适用场合

工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。

1. 在设计的初期，就考虑到产品在后期会进行扩展的情况下，可以使用工厂方法模式；
2. 产品结构较复杂的情况下，可以使用工厂方法模式；

由于使用设计模式是在详细设计时，就需要进行定夺的，所以，需要权衡多方面的因素，而不能为了使用设计模式而使用设计模式。

代码实现

class Product{ public:  //notes: pure virtual functon   virtual void Show()=0;};class ProductA :public Product{ public:   void Show()   {     cout <<"I am ProductA"<<endl;   }};class ProductB: public Product{ public:  void Show()  {    cout <<"I am ProductB"<<endl;  }};class Factory{  public:  //differnt:it became abstract class.not realize!!!合并.变生产为设计科  //it is pure virutal function   virtual Product *CreateProduct()=0;};//new add FactoryA,B; realize CreateProduct Independence;//new create product in FactoryA,B. not in Factory;!!!class FactoryA: public Factory{ public:  Product *CreateProduct()  {   return new ProductA();  }  };class FactoryB :public Factory{ public:  Product *CreateProduct()  {    return new ProductB();  }};int main (){//different:sub factory call CreateProduct now. Factory call CreaeProduct in past!!! Factory *factoryA = new FactoryA(); Product *productA= factoryA->CreateProduct(); productA->Show();  Factory *factoryB = new FactoryB(); Product *productB= factoryB->CreateProduct(); productB->Show();   if (factoryA!=NULL)  {   delete factoryA;   factoryA =NULL;  }  if (productA!=NULL)  {   delete productA;   productA=NULL;  }     if (factoryB!=NULL)  {   delete factoryB;   factoryB =NULL;  }  if (productB!=NULL)  {   delete productB;   productB=NULL;  }    return 0;}