结合简单示例和UML图，讲解工厂模式简单原理。

一、引子

话说十年前，有一个爆发户，他家有三辆汽车（Benz（奔驰）、Bmw（宝马）、Audi（奥迪）），还雇了司机为他开车。不过，爆发户坐车时总是这样：上Benz车后跟司机说“开奔驰车！”，坐上Bmw后他说“开宝马车！”，坐上 Audi后他说“开奥迪车！”。
你一定说：这人有病！直接说开车不就行了？！而当把这个爆发户的行为放到我们程序语言中来，我们发现C语言一直是通过这种方式来坐车的！
幸运的是这种有病的现象在OO语言中可以避免了。下面以Java语言为基础来引入我们本文的主题：工厂模式！

二、简介

工厂模式主要是为创建对象提供了接口。工厂模式按照《Java与模式》中的提法分为三类：
1. 简单工厂模式(Simple Factory)
2. 工厂方法模式(Factory Method)
3. 抽象工厂模式(Abstract Factory)
这三种模式从上到下逐步抽象，并且更具一般性。还有一种分类法，就是将简单工厂模式看为工厂方法模式的一种特例，两个归为一类。两者皆可，这本为使用《Java与模式》的分类方法。
在什么样的情况下我们应该记得使用工厂模式呢？大体有两点：
1.在编码时不能预见需要创建哪种类的实例。
2.系统不应依赖于产品类实例如何被创建、组合和表达的细节
工厂模式能给我们的OOD、OOP带来哪些好处呢？？

三、简单工厂模式

这个模式本身很简单而且使用在业务较简单的情况下。一般用于小项目或者具体产品很少扩展的情况（这样工厂类才不用经常更改）。
它由三种角色组成：
工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑，根据逻辑不同，产生具体的工厂产品。如例子中的Driver类。
抽象产品角色：它一般是具体产品继承的父类或者实现的接口。由接口或者抽象类来实现。如例中的Car接口。
具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现，如例子中的Benz、Bmw类。

来用类图来清晰的表示下的它们之间的关系：

下面就来给那个暴发户治病：在使用了简单工厂模式后，现在暴发户只需要坐在车里对司机说句：“开车”就可以了。来看看怎么用代码实现的：（为方便起见，所有的类放在一个文件中，故有一个类被声明为public）

如果老板要坐奥迪，同理。

这便是简单工厂模式了。那么它带了了什么好处呢？
首先，符合现实中的情况；而且客户端免除了直接创建产品对象的责任，而仅仅负责“消费”产品（正如暴发户所为）。
下面我们从开闭原则上来分析下简单工厂模式。当暴发户增加了一辆车的时候，只要符合抽象产品制定的合同，那么只要通知工厂类知道就可以被客户使用了。（即创建一个新的车类，继承抽象产品Car）那么 对于产品部分来说，它是符合开闭原则的——对扩展开放、对修改关闭；但是工厂类不太理想，因为每增加一辆车，都要在工厂类中增加相应的商业逻辑和判 断逻辑，这显自然是违背开闭原则的。

而在实际应用中，很可能产品是一个多层次的树状结构。由于简单工厂模式中只有一个工厂类来对应这些产品，所以这可能会把我们的上帝类坏了。
正如我前面提到的简单工厂模式适用于业务简单的情况下或者具体产品很少增加的情况。而对于复杂的业务环境可能不太适应了。这就应该由工厂方法模式来出场了！！

四、工厂方法模式
抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java中它由具体的类来实现。
抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。
来用类图来清晰的表示下的它们之间的关系：

话说暴发户生意越做越大，自己的爱车也越来越多。这可苦了那位司机师傅了，什么车它都要记得，维护，都要经过他来使用！于是暴发户同情他说：我给你分配几个人手，你只管管好他们就行了！于是工厂方法模式的管理出现了。代码如下：

使用开闭原则来分析下工厂方法模式。当有新的产品（即暴发户的汽车）产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生成，那么就可以被客户使用，而不必去修改任何已有的代码。（即当有新产品时，只要创建并基础抽象产品；新建具体工厂继承抽象工厂；而不用修改任何一个类）工厂方法模式是完全符合开闭原则的！

使用工厂方法模式足以应付我们可能遇到的大部分业务需求。但是当产品种类非常多时，就会出现大量的与之对应的工厂类，这不应该是我们所希望的。所以我建议在这种情况下使用简单工厂模式与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类（一般是树的叶子中互为兄弟的）使用简单工厂模式来实现。
当然特殊的情况，就要特殊对待了：对于系统中存在不同的产品树，而且产品树上存在产品族（下一节将解释这个名词）。那么这种情况下就可能可以使用抽象工厂模式了。

五、小结

让我们来看看简单工厂模式、工厂方法模式给我们的启迪：
如果不使用工厂模式来实现我们的例子，也许代码会减少很多——只需要实现已有的车，不使用多态。但是在可维护性上，可扩展性上是非常差的（你可以想象一下添加一辆车后要牵动的类）。因此为了提高扩展性和维护性，多写些代码是值得的。

六、抽象工厂模式

先来认识下什么是产品族： 位于不同产品等级结构中，功能相关联的产品组成的家族。

图中的BmwCar和BenzCar就是两个产品树（产品层次结构）；而如图所示的BenzSportsCar和BmwSportsCar就是一个产品族。他们都可以放到跑车家族中，因此功能有所关联。同理BmwBussinessCar和BenzBusinessCar也是一个产品族。
可以这么说，它和工厂方法模式的区别就在于需要创建对象的复杂程度上。而且抽象工厂模式是三个里面最为抽象、最具一般性的。抽象工厂模式的用意为：给客户端提供一个接口，可以创建多个产品族中的产品对象。
而且使用抽象工厂模式还要满足一下条件：
1.系统中有多个产品族，而系统一次只可能消费其中一族产品
2.同属于同一个产品族的产品以其使用。
来看看抽象工厂模式的各个角色（和工厂方法的如出一辙）：
抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。
具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。在java中它由具体的类来实现。
抽象产品角色：它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类或者接口来实现。
具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在java中由具体的类来实现。

其中：BenzSportCar和BenzBusinessCar属于产品树；同理BmwSportCar和BmwBusinessCar。而BenzSportCar和BmwSportCar和AudiSportCar属于产品族。

所以抽象工厂模式一般用于具有产品树和产品族的场景下。

抽象工厂模式的缺点：如果需要增加新的产品树，那么就要新增三个产品类，比如VolvoCar，VolvoSportCar,VolvoSportCar，并且要修改三个工厂类。这样大批量的改动是很丑陋的做法。

所以可以用简单工厂配合反射来改进抽象工厂：
UML图略。

策略模式

从策略一词来看,策略模式是种倾向于 行为的模式.有点类似找仗时的做战方案，一般司令员在做战前都会根据实际情况做出几套不同的方案，如果当时情况有变，就会根据相应的条件来判定用哪一套方案来替换原定方案。但无论如何替换，替换多少次，仗还是要打的。

举例：导出成EXCEL，WORD，PDF文件的功能，这三类导出虽然具体操作略有不同，但是大部分都相同。

策略模式与工厂模式从uml图上来说，基本一致。只是强调的封装不同。我们以工厂模式和策略模式的比较来讲解策略模式。

工厂模式我们可以做如下理解：假设有Audi的公司生产汽车，它掌握一项核心的技术就是生产汽车，另一方面，它生产的汽车是有不同型号的，并且在不同的生产线上进行组装。当客户通过销售部门进行预定后，Audi公司将在指定的生产线上为客户生产出它所需要的汽车。

策略(Strategy)模式在结构上与工厂模式类似，唯一的区别是工厂模式实例化一个产品的操作是在服务端来做的，换句话说客户端传达给服务端的只是某种标识，服务端根据该标识实例化一个对象。而策略模式的客户端传达给服务端的是一个实例，服务端只是将该实例拿过去在服务端的环境里执行该实例的方法。这就好比一个对汽车不甚了解的人去买车，他在那一比划，说要什么什么样的，销售部门根据他的这个“比划”来形成一份订单，这就是工厂模式下的工作方式。而策略模式下那个顾客就是个行家，他自己给出了订单的详细信息，销售部门只是转了一下手就交给生产部门去做了。通过两相对比，我们不难发现，采用工厂模式必须提供足够灵活的销售部门，如果用户有了新的需求，销售部门必须马上意识到这样才可以做出合适的订单。所以倘一款新车出来了，生产部门和销售部门都需要更新，对顾客来说也需要更新对新车的描述所以需要改动的地方有三处。而策略模式中的销售部门工作比较固定，它只负责接受订单并执行特定的几个操作。当一款新车出来时，只需要对服务端的生产部门和客户端的代码进行更新，而不需要更新销售部门的代码。

技术支持： 简单工厂和策略的基础都是因为面向对象的封装与多态。他们实现的思想都是先设定一个抽象的模型并从该模型派生出符合不同客户需求的各种方法，并加以封装。

工厂模式和策略模式的区别在于实例化一个对象的位置不同，对工厂模式而言，实例化对象是放在服务端的，即放在了工厂类里面；

而策略模式实例化对象的操作在客户端，服务端的“销售部门”只负责传递该对象，并在服务端的环境里执行特定的操作。。。

工厂模式要求服务端的销售部门足够灵敏，而策略模式由于对策略进行了封装，所以他的销售部门比较傻，需要客户提供足够能区分使用哪种策略的参数，而这最好的就是该策略的实例了。

策略模式的优缺点

策略模式的主要优点有：

• 策略类之间可以自由切换，由于策略类实现自同一个抽象，所以他们之间可以自由切换。
• 易于扩展，增加一个新的策略对策略模式来说非常容易，基本上可以在不改变原有代码的基础上进行扩展。
• 避免使用多重条件，如果不使用策略模式，对于所有的算法，必须使用条件语句进行连接，通过条件判断来决定使用哪一种算法，在上一篇文章中我们已经提到，使用多重条件判断是非常不容易维护的。

策略模式的缺点主要有两个：

• 维护各个策略类会给开发带来额外开销，可能大家在这方面都有经验：一般来说，策略类的数量超过5个，就比较令人头疼了。
• 必须对 客户端（调用者）暴露所有的策略类，因为使用哪种策略是由客户端来决定的，因此，客户端应该知道有什么策略，并且了解各种策略之间的区别，否则，后果很严 重。例如，有一个排序算法的策略模式，提供了快速排序、冒泡排序、选择排序这三种算法，客户端在使用这些算法之前，是不是先要明白这三种算法的适用情况？ 再比如，客户端要使用一个容器，有链表实现的，也有数组实现的，客户端是不是也要明白链表和数组有什么区别？就这一点来说是有悖于迪米特法则的。

适用场景

做面向对象设计的，对策略模式一定很熟悉，因为它实质上就是面向对象中的继承和多态，在看完策略模式的通用代码后，我想，即使之前从来没有听说过策略模式，在开发过程中也一定使用过它吧？至少在在以下两种情况下，大家可以考虑使用策略模式，

• 几个类的主要逻辑相同，只在部分逻辑的算法和行为上稍有区别的情况。
• 有几种相似的行为，或者说算法，客户端需要动态地决定使用哪一种，那么可以使用策略模式，将这些算法封装起来供客户端调用。

策略模式是一种简单常用的模式，我们在进行开发的时候，会经常有意无意地使用它，一般来说，策略模式不会单独使用，跟模版方法模式、工厂模式等混合使用的情况比较多。

大粒度的 if --else if...可以使用 工厂+策略模式搞定。