------解决方案--------------------是不是一个工厂只负责生产一个产品？
不是。
在工厂模式中，工厂不是负责生产一个产品的，而是负责生产同一系列的产品的，这些产品在某个特性上有不同.
------解决方案--------------------7楼不已经给了例子了啊 ~
------解决方案--------------------哎，不知道楼主要啥，是要抽象工厂吗？抽象工厂就是把工厂类抽象出来
是要这样的吗？
其实上面的UML图只是简单例子，可以自己扩展
------解决方案--------------------图太大了 晕死
------解决方案--------------------就是每个派生出来的工厂可以生产多个系列的产品~~
------解决方案--------------------工厂应该是能产生多种对象产品的
你可以做一个运算工厂，来生产加法对象、减法对象、乘法对象等
可以做一个加法工厂，来生产整数加法、小数加法、复数加法等
可以做一个手机工厂，来生产翻盖手机、直板手机、滑盖手机
可以看看《大话设计模式》，挺有意思的一本书
------解决方案--------------------所谓工厂，就是生产对象实例的类。把对象实例化的逻辑交给工厂实现。为什么要这样呢？
1、有一系列的类（即产品类）的对象需要实例化，而且这一系列的类可以被以被抽象到相同的接口；
2、能够扩展这个类的系列，且对客户端不产生大的影响（客户端只使用“抽象接口”，而不需知道被调用对象的是这一系列类中的具体哪个类型）；
同时，简单工厂、工厂方法、抽象工厂这三者在产品类的实例化逻辑上有一定不同：
1、简单工厂：客户端要以一定的方式（例如传递参数、配置信息等方式）告知工厂，然后工厂再具体实例化客户端需要的产品类型的实例，但返回的是抽象接口。其中，根据客户端的要求，工厂选择合适的产品类类型的逻辑是在工厂内部，当扩展产品类数量的时候，面临着修改的需求。
2、工厂方法：当客户端需要某个确定的产品类对象实例时，先直接实例化某个工厂类的对象（工厂的抽象接口），然后再有这个工厂类对象实例实例化客户端真正需要的产品类对象实例（产品的抽象接口）。很明显在简单工厂、工厂方法这两种模式中，客户端在具体的产品类类型的选择过程，其选择逻辑的实现方式和位置是不同的。继续保留了产品类易扩展的特点，同时还改善了由于扩展带来的选择逻辑修改的风险。
3、抽象工厂：选择逻辑类似于工厂方法。但工厂方法相是依据单个产品类特征作出选择，而抽象工厂是依据所有产品类的共同特征作出选择的。如果说把抽象工厂看作是由一些工厂合成的工厂，那么一次选择意味着同时选择了多个工厂（工厂方法中的工厂）。
------解决方案--------------------
------解决方案--------------------工厂方法的优势就在于一个工厂可以生产很多具有类似属性的产品，如果一个工厂只生产一个产品那就没有意义了。
------解决方案--------------------以图形类为例：
class CGraph;
class CRectangle : public CGraph
class CTriangle : public CGraph
class CElipse : public CGraph
CGraph *GraphFactory(const int GraphType);
CRectangle *Rect = dynamic_cast<CRectangle*>(GraphFactory(GRAPH_TYPE_RECT));
