工厂方法模式

一.定义

工厂方法模式（Factory Method Pattern）是一种创建型设计模式，它提供了一种将对象的创建委托给子类的方式。工厂方法模式通过定义一个创建对象的接口，但是具体的对象实例化由子类决定。

在工厂方法模式中，有一个抽象的工厂类（Creator），它声明了一个用于创建对象的工厂方法（Factory Method），该方法返回一个抽象产品类（Product）的实例。具体的产品创建由实现该抽象工厂类的具体工厂子类（Concrete Creator）来实现。
具体的类图结构如下:

代码如下:
抽象产品类

具体产品类

抽象工厂类

具体工厂类

场景类

二.例子

我们还是来举一个例子来说明工厂方法模式究极是怎么样的.这里采取的例子,是神话故事女娲造人的故事.来展开的,具体过程如下:
东汉《风俗通》记录了一则神话故事:“开天辟地，未有人民，女娲搏黄土做人”，讲述的内容就是大家非常熟悉的女娲造人的故事。开天辟地之初，大地上并没有生物，只有苍茫大地,纯粹而洁净的自然环境，寂静而又寂寞，于是女娲决定创造一个新物种（即人类）来增加世界的繁荣，怎么制造呢?
别忘了女娲是神仙，没有办不到的事情，造人的过程是这样的:首先，女娲采集黄土捏成人的形状，然后放到八卦炉中烧制，最后放置到大地上生长，工艺过程是没有错的，但是意外随时都会发生:
第一次烤泥人，感觉应该熟了，往大地上一放，哇，没烤熟!于是一个白人诞生了!(这也是缺乏经验的最好证明)
第二次烤泥人，上一次没烤熟，这次多烤-一会儿，放到世间一看，嘿，熟过头了，于是黑人诞生了!
第三次烤泥人，一-边烧制一边察看，直到表皮微黄，嘿，真正好，于是黄色人种出现了!这个造人过程是比较有意思的，是不是可以通过软件开发来实现这个过程呢?古人云:“三人行，必有我师焉”，在面向对象的思维中，万物皆对象，是对象我们就可以通过软件设计来实现。首先对造人过程进行分析，该过程涉及三个对象:女娲、八卦炉、三种不同肤色的人。女娲可以使用场景类Client来表示，八卦炉类似于一个工厂，负责制造生产产品（即人类)，三种不同肤色的人，他们都是同一个接口下的不同实现类，都是人嘛，只是肤色、语言不同，对于八卦炉来说都是它生产出的产品。分析完毕，我们就可以画出类图入下:

类图比较简单，AbstractHumanFactory是一个抽象类，定义了一个八卦炉具有的整体功能，HumanFactory为实现类，完成具体的任务—创建人类，Human接口是人类的总称，其三个实现类分别为三类人种，NvWa类是一个场景类，负责模拟这个场景，执行相关的任务。
具体的业务代码如下:
人类总称

其他实现类人种

所有的人种定义完毕，下一步就是定义一个八卦炉，然后烧制人类。我们想象一下，女娲最可能给八卦炉下达什么样的生产命令呢?应该是“给我生产出一个黄色人种(YellowHuman类)”，而不会是“给我生产一个会走、会跑、会说话、皮肤是黄色的人种”，因为这样的命令增加了交流的成本，作为一个生产的管理者，只要知道生产什么就可以了，而不需要事物的具体信息。通过分析，我们发现八卦炉生产人类的方法输人参数类型应该是Human接口的实现类，这也解释了为什么类图上的AbstractHumanFactory抽象类中createHuman方法的参数为Class类型。其源代码如代码清单如下所示:

注意，我们在这里采用了泛型(Generic)，通过定义泛型对createHuman的输入参数产生两层限制:
必须是Class类型，
必须是Human的实现类。
人类创建工厂

女娲类

三.结论

工厂方法的优点

首先，良好的封装性，代码结构清晰。一个对象创建是有条件约束的，如一个调用者需要一个具体的产品对象，只要知道这个产品的类名(或约束字符串）就可以了，不用知道创建对象的艰辛过程，降低模块间的耦合。
其次，工厂方法模式的扩展性非常优秀。在增加产品类的情况下，只要适当地修改具体的工厂类或扩展一个工厂类，就可以完成“拥抱变化”。例如在我们的例子中，需要增加一个棕色人种，则只需要增加一个BrownHuman类，工厂类不用任何修改就可完成系统扩展。
再次，屏蔽产品类。这一特点非常重要，产品类的实现如何变化，调用者都不需要关心，,它只需要关心产品的接口，只要接口保持不变，系统中的上层模块就不要发生变化。因为产品类的实例化工作是由工厂类负责的，一个产品对象具体由哪一个产品生成是由工厂类决定的。在数据库开发中，大家应该能够深刻体会到工厂方法模式的好处:如果使用JDBC连接数据库，数据库从MySQL切换到Oracle，需要改动的地方就是切换一下驱动名称（前提条件是SQL语句是标准语句)，其他的都不需要修改，这是工厂方法模式灵活性的一个直接案例。
最后，工厂方法模式是典型的解耦框架。高层模块值需要知道产品的抽象类，其他的实现类都不用关心，符合迪米特法则，我不需要的就不要去交流，也符合依赖倒置原则，只依赖产品类的抽象，当然也符合里氏替换原则，使用产品子类替换产品父类，没问题!

工厂方法的扩展

工厂方法模式有很多扩展，而且与其他模式结合使用威力更大，下面将介绍4种扩展。

缩小为简单工厂

我们这样考虑一个问题:一个模块仅需要一个工厂类，没有必要把它产生出来，使用静态的方法就可以了，根据这一要求，我们把上例中的AbstarctHumanFactory修改一下，类图如图

我们在类图中去掉了AbstractHumanFactory抽象类，同时把createHuman方法设置为静态类型，简化了类的创建过程，变更的源码仅仅是HumanFactory和NvWa类，HumanFactory如代码如下:

HumanFactory类仅有两个地方发生变化:去掉继承抽象类，并在createHuman前增加static关键字，工厂类发生变化，也同时引起了调用者NvWa的变化，如代码清单如下:

运行结果没有发生变化，但是我们的类图变简单了，而且调用者也比较简单，该模式是工厂方法模式的弱化，因为简单，所以称为简单工厂模式(Simple Factory Pattern)，也叫做静态工厂模式。在实际项目中，采用该方法的案例还是比较多的，其缺点是工厂类的扩展比较困难，不符合开闭原则，但它仍然是一个非常实用的设计模式。

升级为多个工厂类

当我们在做一个比较复杂的项目时，经常会遇到初始化一个对象很耗费精力的情况，所有的产品类都放到一个工厂方法中进行初始化会使代码结构不清晰。例如，一个产品类有5个具体实现，每个实现类的初始化（不仅仅是new，初始化包括new一个对象，并对对象设置一定的初始值）方法都不相同，如果写在一个工厂方法中，势必会导致该方法巨大无比，那该怎么办?
考虑到需要结构清晰，我们就为每个产品定义一个创造者，然后由调用者自己去选择与哪个工厂方法关联。我们还是以女娲造人为例，每个人种都有一个固定的八卦炉，分别造出黑色人种、白色人种、黄色人种，修改后的类图如图所示

每个人种(具体的产品类）都对应了一个创建者，每个创建者都独立负责创建对应的产品对象，非常符合单一职责原则，按照这种模式我们来看看代码变化。
黑色人种

黄色人种

白色人种

场景类

运行结果还是相同。我们回顾一下，每一个产品类都对应了一个创建类，好处就是创建类的职责清晰，而且结构简单，但是给可扩展性和可维护性带来了一定的影响。为什么这么说呢?如果要扩展一个产品类，就需要建立一个相应的工厂类，这样就增加了扩展的难度。因为工厂类和产品类的数量相同，维护时需要考虑两个对象之间的关系。
当然，在复杂的应用中一般采用多工厂的方法，然后再增加一个协调类，避免调用者与各个子工厂交流，协调类的作用是封装子工厂类，对高层模块提供统一的访问接口。