设计模式随笔-简单工厂，工厂方法，抽象工厂

1. 官方解释

工厂模式专门负责将大量有共同接口的类实例化。

工厂模式可以动态决定将

哪一个类实例化，不必事先知道每次要实例化哪一个类。

工厂模式专门负责将大量有共同接口的类实例化。工厂模式可以动态决定将哪一个类实例化，不必事先知道每次要实例化哪一个类。

工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。

分类：

工厂模式在《Java与模式》中分为三类：
1）简单工厂模式（Simple Factory）：不利于产生系列产品；
2）工厂方法模式（Factory Method）：又称为多形性工厂；
3）抽象工厂模式（Abstract Factory）：又称为工具箱，产生产品族，但不利于产生新的产品；
这三种模式从上到下逐步抽象，并且更具一般性。
GOF在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的一种特例，两者归为一类。

2. 个人理解

搞这么多名词，很混淆的。我一直喜欢用大白话来描述，个人总结了一下（大白话，牛人请略过吧）

1）简单工厂： 用一个具体来充当工厂的角色，一个具体工厂类包含所有产品的创建，由一个具体的类去创建其他类的实例，父类是相同的，父类也是具体的。  

2）工厂方法：工厂类有抽象类和具体类，具体的一个工厂类只创建一个具体的产品，多个具体的产品用多个工厂类 。一个抽象的父类定义公共接口，子类负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成。

3）抽象工厂：工厂方法只是产生同一类产品的工厂，抽象工厂实际和工厂方法的实现是一样的，工厂方法一个具体工厂类里面生产一个具体产品，抽象工厂一个具体工厂类里面可以生产不同类别的产品。用来生产不同产品族的全部产品。（没能理解为什么起抽象工厂的概念，工厂方法也是抽象的啊？有待进一步理解啊） 也可以理解为多个工厂方法，然后将工厂方法合并

3. 直接上 UML图

简单工厂

工厂方法

抽象工厂

4. 举例

在这里就不单独举例了，网上一搜一大把

5 优缺点

1）如果有许多地方都需要生成A的对象，那么你需要写很多A a=new A（）。

如果需要修改的话，你要修改许多地方。但是如果用工厂模式，你只需要修改工厂代码。其他地方引用工厂，可以做到只修改一个地方，其他代码都不动，就是解耦了。

2）动态实现
如果需要像前面自行车的例子一样，创建一些用不同方式实现同一接口的对象，
那么可以使用一个工厂方法或简单工厂对象来简化选择实现的过程。
这种选择可以是明确进行的也可以是隐含的。前者如自行车那个例子，顾客可以选择需要的自行车型号；
在这些场合下，你通常要与一系列实现了同一个接口、可以被同等对待的类打交道。这是Java中使用工厂模式的最常见的原因。

3）节省设置开销
如果对象需要进行复杂并且彼此相关的设置，那么使用工厂模式可以减少每种对象所需的代码量。
如果这种设置只需要为特定类型的所有实例执行一次即可，这种作用尤其突出。
把这种设置代码放到类的构造函数中并不是一种高效的做法，这是因为即便设置工作已经完成，
每次创建新实例的时候这些代码还是会执行，而且这样做会把设置代码分散到不同的类中。
工厂方法非常适合于这种场合。它可以在实例化所有需要的对象之前先一次性地进行设置。
无论有多少不同的类会被实例化，这种办法都可以让设置代码集中在一个地方。
如果所用的类要求加载外部库的话，这尤其有用。工厂方法可以对这些库进行检查并动态加载那些未找到的库。这些设置代码只存在于一个地方，因此以后改起来也方便得多。

4) 用许多小型对象组成一个大对象
工厂方法可以用来创建封装了许多较小对象的对象。考虑一下自行车对象的构造函数。
自行车包含着许多更小的子系统：车轮、车架、传动部件以及车闸等。
如果你不想让某个子系统与较大的那个对象之间形成强耦合，而是想在运行时从许多子系统中进行挑选的话，
那么工厂方法是一个理想的选择。
使用这种技术，某天你可以为售出的所有自行车配上某种链条，要是第二天找到另一种更中意的链条，
可以改而采用这个新品种。实现这种改变很容易，因为这些自行车类的构造函数并不依赖于某种特定的链条品种。