设计模式之简单工厂模式(Simple Factory)

时间:2022-12-31 20:32:57

 今天呢,要学习的设计模式是“简单工厂模式”,这是一个实现起来比较简单的设计模式,但是确是经常使用的设计模式,同时呢,使用简单工厂模式好处也是比较多的。可以说学习了这个模式性价比还是比较高的。

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.代码实现简单工厂模式

  看看上面的例子代码实现是什么样的吧,代码写的好,往往更好理解设计模式具体是怎么回事!!(代码总只实现一部分子类)

设计模式之简单工厂模式(Simple Factory)
 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 }
设计模式之简单工厂模式(Simple Factory)

 

  准备工作做完了,那么在客户端那边怎么使用这些类呢?

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原则,这里不多少了,学习工厂方法模式的时候对比着来吧,这样可能效果更好!!)