关于工厂模式

 

今天受打击了，晚上回来的时候，师兄看我在看设计模式，于是问我“工厂模式”有什么好？一时语塞，顿时想不起来，只记得貌似是在里面产生一堆东西的，减少代码修改量的，又想起貌似挺多设计模式都是用来解耦合的，于是犹犹豫豫地回答“解耦合？”然后就再想不出任何实质的能够回答师兄的疑问的东西，用蕾蕾的话说，就是“又没有通过师兄的考验”。。。好在另一个学长貌似对这个还挺有研究，于是一路上都在讲解，在他的讲解中我总算也慢慢想起来。

以下是我在还未翻书的情况下，凭着残存的记忆对工厂模式的理解：

工厂模式：在工厂类的方法中实现对一些类的对象的创建，目的是便于代码的扩展、修改与维护，并且实现代码的重用。

使用情形：当一些类的实例化代码较多，或者需要根据条件来创建对象（这个貌似和策略模式有点联系），要通过一些参数来实现对象的创建时，将这部分代码用工厂类的一个方法来实现，有以下好处：

1、代码重用：这部分代码可以在多处调用；

2、便于修改：当要更改对象创建的参数或者是个数、类型等时，只需要修改工厂类的方法，而不需要再到每一处对象创建的地方去修改；

3、安全性：例如当需要对代码进行扩展或修改时，不需要将所有的实现代码和功能过程都交给修改人员，而只需要将工厂类交给修改人员，从而避免了修改人员对不需要修改的地方进行的擅自修改。

通过再次翻看《大话设计模式》，发现原来有两个工厂模式：

一个是简单工厂模式，是用一个计算器实现的例子来讲解，在工厂类中，将运算符号（字符串）作为输入参数，根据该字符串在switch中的匹配情况来确定实例化哪个运算符对象。其实也就是将较为复杂的对象实例化过程单独拎出来，在工厂类的方法中确定实例化何种类型的对象。

工厂方法模式，以雷锋的例子引入，同样是实现计算器，但是是对每个运算符类（如Add类）都添加一个相应的运算符工厂类（如AddFactory），而这些工厂类都实现一个工厂接口（如IFactory），并且拥有一个同名方法（CreateOperation）可以返回一个相应的运算符类的对象，在客户端就可以通过实例化一个工厂接口类型（IFactory）的运算符工厂类（AddFactory）的对象，并通过调用该对象的CreateOperation方法来获得运算符对象。的确是绕了很多，增加了N+1个类，UML图也大了一倍，感觉调用方法也复杂了很多，而且在修改的时候还是要去改客户端，感觉还不如简单工厂模式。。。

简单工厂模式VS工厂方法模式：

简单工厂模式：最大优点在于工厂类中包含了必要的逻辑判断（switch-case），根据客户端的选择条件（如字符参数参数'+')动态实例化相关的类（如Add类），对于客户端来说，去除了与具体产品的依赖。

但是在增加一个类时，需要修改逻辑判断（如增加case），而可能导致对原有类的修改，这样不但对扩展开放了，也对修改开放了，就违背了开放-封闭原则。于是，工厂方法模式就来了。

工厂方法模式（Factory Method）：定义一个用于创建对象的接口，让子类决定初始化哪一个类。工厂方法使一个类的实例化延迟到子类。

在简单工厂模式的中，工厂类与分支耦合，因此依据依赖倒转原则，把工厂类抽象出一个接口，这个借口只有一个方法，就是创建抽象产品的工厂方法。然后，所有要生产具体类的工厂，就去实现这个接口，从而将一个简单工厂模式的工厂类变成了一个工厂抽象接口和多个具体生成对象的工厂，当要增加类型时（如增加一种运算符），就不需要更改原有的工厂类，，只需要添加此功能的类和相应的工厂类就行了。

工厂方法模式实现时，客户端需要决定实例化哪一个工厂来实现运算类，选择判断问题还是存在的，也就是说，工厂方法把简单工厂的内部逻辑判断一到了客户端代码来进行，想要加功能，本来是改工厂类的，而现在要改客户端。

工厂方法克服了简单工厂违背开放-封闭原则的缺点，又保持了封装对象创建过程的优点，它们都是集中了封装对象的创建，使得要更换对象时，不需要做大的改动就可以实现，降低了客户端与产品对象的耦合。工厂方法模式是简单工厂模式的进一步抽象和推广。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。但缺点是由于每增加一个产品，就需要家一个产品工厂的类，增加了额外的开发量。

利用“反射”可以解决避免分支判断的问题（关于“反射”我还没看到，以后慢慢学吧）欢迎积极讨论！