设计模式之2工厂模式

工厂，顾名思义，就是生产产品的地方，所以工厂模式也跟生产对象脱不了关系。那么，什么是工厂模式呢？在java中又是如何实现的？不要着急，我们一起看下。

---

一、什么是工厂模式？

工厂模式（Factory Pattern）是我们最常用的实例化对象模式了，是用工厂方法代替new操作的一种模式。所以客户端无须关心其具体实现，因此会给系统带来更大的可扩展性和尽量少的修改量（开闭原则）。

二、如何实现工厂模式？

1.简单工厂

定义了一个创建对象的类，由这个类来封装实例化对象的行为(代码)。

简单工厂UML类图

上图就是非常常见的简单工厂UML类图，我们之前有强调过，要学设计模式，必先会类图。从这个类图我们可以清楚的看到简单工厂的设计理念。它把创建产品Product的代码包装进SimpleProductFactory类中，当以后修改产品的生产方式时，只需要修改SimpleProductFactory类就可以了。这样就把具体实例化的过程，从客户端的代码中解耦出来，不必再理会到底有多少个客户端使用到了Product。

到事情并没有到此为止，如果我不止有一种产品呢？如果所有创建产品的过程都集中在SimpleProductFactory类中的话，这会导致这个简单工厂类很庞大臃肿。。显然，如果面对这种情况，我们需要进一步解耦。

2.工厂方法模式

从工厂方法模式的UML类图中，我没可以清楚的看到共有4种角色，分别是抽象产品角色，具体产品角色，抽象工厂角色，具体工厂角色。这样就实现了产品间的解耦。在简单工厂中，当有很多类产品的时候，不得不修改之前的代码。但工厂方法模式把具体产品的创建推迟到工厂类的子类（具体工厂）中，此时工厂类不再负责所有产品的创建，而只是给出具体工厂必须实现的接口，这样工厂方法模式在添加新产品的时候就不修改工厂类逻辑而是添加新的工厂子类，符合开放封闭原则，克服了简单工厂模式中缺点。

但是我们看待一个问题要一分为二，我们也应该看到，添加新产品时，除了增加新产品类外，还要提供与之对应的具体工厂类，系统类的个数将成对增加，在一定程度上增加了系统的复杂度。同时，有更多的类需要编译和运行，会给系统带来一些额外的开销。

工厂方法UML类图

工厂方法模式虽然保证了工厂方法内的对修改关闭（这里指新增一个产品），但对于使用工厂方法的类，如果要更换另外一种产品，仍然需要修改实例化的具体工厂类。另外一个具体工厂只能创建一种具体产品。显然如果有必要，还需进一步解耦。

3.抽象工厂模式

抽象工厂UML类图

抽象工厂模式其实跟工厂方法模式大同小异，但是工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。使用抽象工厂模式一般要满足以下条件。1）系统中有多个产品族，每个具体工厂创建同一族但属于不同等级结构的产品。2）系统一次只可能消费其中某一族产品，即同族的产品一起使用。

可以知道，抽象工厂针对的是产品族的创建。（有关产品族的知识参考百度百科等）。其缺点是：当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。

三、如何使用工厂模式

工厂模式应该是使用最广泛的设计模式之一，毕竟任何代码都是从新建一个开始的。在很多底层的代码框架中，也会出现很多类似XXXFactory的类。他们或多或少都运用了工厂模式的思想。

无论是简单工厂，还是工厂方法模式，或是抽象工厂模式都有它们自己的内在特点，认清它们的异同点是十分必要的。在实际项目中，我们应该能够根据实际情况选择最合适的。

纸上得来终觉浅，绝知此事要躬行........