原文地址：http://www.cnblogs.com/BeyondAnyTime/archive/2012/07/06/2579100.html
今天呢，要学习的设计模式是“简单工厂模式”，这是一个实现起来比较简单的设计模式，但是确是经常使用的设计模式，同时呢，使用简单工厂模式好处也是比较多的。可以说学习了这个模式性价比还是比较高的。
1.宏观理解简单工厂模式
想来想去，还是觉得这个例子比较好：现在要完成一个计算器的功能，要求输入两个数A，B和一个运算符号（+，-，*，%），能够输出运算结果。注意哦，我们这里说的是面向对象的编程，别总想面向过程的思路。既然是面向对象，那首先我们想想要有哪些类吧！先想一想，可不可以这样有一个类Operator里面包含add，sub，mult，div四个方法，然后再包含两个成员变量A和B呢？通过这个类是可以完成目前的要求，可以要是从软件工程的角度，需求变化在软件开发过程中是无法避免的，那么现在又要完成取余（%）操作呢？这是要修改Operator类了吧，这就违背面向对象设计模式的OCP原则了。这显然不是一个好的设计。实际上这是一个典型的利用“简单工厂模式”的例子，那看看利用简单工厂模式怎么做吧。首先声明一个Operator类，类中包含operation方法，然后声明四个类Add，Sub，Sub，Mult四个类继承Operator类，四个子类中重写operation方法，分别完成加，减，乘，除操作。现在要说工厂了，工厂实际上也是一个类Factory，类中包括一个Operator类型成变量和CreateOperator（）方法，该类用于创建各种Operator实例，可以根据传递的参数动态创建Add，Sub，Sub，Mult各种实例。这时如果要增加取余（%）操作，只需要建一个取余操作的子类，然后再工厂类中增加一点点创建的代码就KO了。这样的话，客户端只需要实例化一个工厂类就可以创建各种Operator对象了。想想都思路清晰，怎一个“爽”子字了得。具这样做都要什么好处呢？？等等再说，还是先看看实现的代码是什么样的吧！！！
2.代码实现简单工厂模式
看看上面的例子代码实现是什么样的吧，代码写的好，往往更好理解设计模式具体是怎么回事！！（代码总只实现一部分子类）
1 class Operator
2 {
3 private:
4 double A;
5 double B;
6 public:
7 double operation();
8 }
9 //加法子类
10 class Add : public Operator
11 {
12 double operation()
13 {
14 return A + B;
15 }
16 }
17 //减法子类
18 class Sub : public Operator
19 {
20 double operation()
21 {
22 return A - B;
23 }
24 }
25 //工厂类
26 class OperatorFactory
27 {
28 private:
29 Operator op;
30 Operator CreateOperator(string OperationType)
31 {
32 switch(OperationType)
33 {
34 case "+":
35 op = new Add();
36 break;
37 case "-":
38 op = new Sub();
39 break;
………………
42 }
43 }
44 }
准备工作做完了，那么在客户端那边怎么使用这些类呢？
1 Operator op;
2 op = OperatorFactory.CreateOperator("+");
3 op.A = 23;
4 op.B = 20;
5 cout<<op.Operation()<<endl;
3.简单工厂模式的好处
看出来这样做有什么好处了吗？先看看木有工厂类是什么样的吧。这时，在客户端只要是使用四种子类，就要实例化子类，不断的实例化，并且客户端也要花费大量的代码决定具体实例化的哪个子类。这时如果子类的实例化方式要是改变，那么要改动的地方就多了去了。使用了简单工厂模式，在客户端我们只需要调用OperatorFactory实例就可以很方便的使用这些类了，减轻了客户端的压力，同时使得系统的可扩展性，也更易于复用了。这也正式很多设计模式要达到的目的。
不妨看看网友是怎么说的：
网摘1：
面向对象的设计的目的之一,就是把责任进行划分,以分派给不同的对象。我们推荐这种划分责任的作法, 是因为它和封装(Encapsulation)和分派(Delegation)的精神是相符合的。创建性模式把对象的创立过程封装起来,使得创立实例的责任与使用实例的责任分割开, 并由专门的模块分管实例的创建,而系统在宏观上不再依赖于对象创立过程的细节。
网摘2：
举个更实际例子，比如你写了个应用，里面用到了数据库的封装，你的应用可以今后需要在不同的数据库环境下运行，可能是oracle,db2,sql server等，那么连接数据库的代码是不一样的，你用传统的方法，就不得不进行代码修改来适应不同的环境，非常麻烦，但是如果你采用工厂类的话，将各种可能的数据库连接全部实现在工厂类里面，通过你配置文件的修改来达到连接的是不同的数据库，那么你今后做迁移的时候代码就不用进行修改了。
（注：实际上简单工厂模式也是有缺陷的，并不是完全符合OCP原则，这里不多少了，学习工厂方法模式的时候对比着来吧，这样可能效果更好！！）