初识工厂方法模式
定义
定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到其子类。
结构和说明
Product：定义工厂方法所创建的对象的接口，也就是实际需要使用的对象的接口
ConcreteProduct：具体的Product接口的实现对象。
Creator：创建器，声明工厂方法
ConcreteCreator：具体的创建器对象，覆盖实现Creator定义的工厂方法，返回具体的Product实例
体会工厂方法模式
导出数据的应用框架 考虑这样一个实际应用：实现一个导出数据的应用框架，来让客户选择数据的导出方式，并真正执行数据导出。 通常这种系统，在导出数据上，会有一些约定的方式，比如导出成：文本格式、数据库备份形式、Excel格式、Xml格式等等
不用模式的解决方案 -- 看代码实例
存在的问题 对于实现导出数据的业务功能对象，它需要创建ExportFileApi的具体实例对象，但是它只知道ExportFileApi接口，而不知道其具体的实现。那该怎么办呢？
使用模式的解决方案
理解工厂方法模式
认识工厂方法模式
1：工厂方法模式的功能 工厂方法的主要功能是让父类在不知道具体实现的情况下，完成自身的功能调用，而具体的实现延迟到子类来实现。
2：实现成抽象类 工厂方法的实现中，通常父类会是一个抽象类，里面包含创建所需对象的抽象方法，这些抽象方法就是工厂方法.ps:子类在实现抽象方法时候，通常并不是真正的由子类来实现具体的功能，而是在子类的方法里面做选择，选择具体的产品实现对象。
3：实现成具体的类 也可以把父类实现成为一个具体的类，这种情况下，通常是在父类中提供获取所需对象的默认实现方法，这样就算没有具体的子类，也能够运行 。
4：工厂方法的参数和返回值 工厂方法的实现中，可能需要参数，以便决定到底选用哪一种具体的实现。一般工厂方法返回的是被创建对象的接口对象，当然也可以是抽象类或者一个具体的类的实例。
5：谁来使用工厂方法创建的对象
（1）在工厂方法模式里面，应该是Creator中的其它方法在使用工厂方法创建的对象
（2）客户端应该是使用Creator对象，或者是使用由Creator创建出来的对象，这个时候工厂方法创建的对象，是Creator中的某些方法使用。在某些情况下，客户端可能会使用由Creator创建出来的对象，这个时候工厂方法创建的对象，是构成客户端需要的对象的一部分。
小结一下：在工厂方法模式里面，客户端要么使用Creator对象，要么使用Creator创建的对象，一般客户端不直接使用工厂方法。当然也可以直接把工厂方法暴露给客户端操作，但是一般不这么做
工厂方法模式的调用顺序示意图 先看看客户端使用由Creator创建出来的对象情况的调用顺序示意图
接下来看看客户端使用Creator对象时候的调用顺序示意图
工厂方法模式与IoC/DI
1：概念 依赖注入：应用程序依赖容器创建并注入它所需要的外部资源 控制反转：容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。
2：理解 (1)参与者都有谁？
一般有三方参与者，一个是某个对象；一个是IoC/DI的容器；另一个是某个对象的外部资源。 又要名词解释一下，某个对象指的就是任意的、普通的Java对象; IoC/DI的容器简单点说就是指用来实现IoC/DI功能的一个框架程序；对象的外部资源指的就是对象需要的，但是是从对象外部获取的，都统称资源，比如：对象需要的其它对象、或者是对象需要的文件资源等等。
(2)依赖：谁依赖于谁？为什么需要依赖？
当然是某个对象依赖于IoC/DI的容器。对象需要IoC/DI的容器来提供对象需要的外部资源。
(3)注入：谁注入于谁？到底注入什么？
很明显是IoC/DI的容器 注入 某个对象。就是注入某个对象所需要的外部资源。
(4)控制反转：谁控制谁？控制什么？为何叫反转（有反转就应该有正转了）？
当然是IoC/DI的容器来控制对象了。主要是控制对象实例的创建。反转是相对于正向而言的，那么什么算是正向的呢？考虑一下常规情况下的应用程序，如果要在A里面使用C，你会怎么做呢？当然是直接去创建C的对象，也就是说，是在A类中主动去获取所需要的外部资源C，这种情况被称为正向的。那么什么是反向呢？就是A类不再主动去获取C，而是被动等待，等待IoC/DI的容器获取一个C的实例，然后反向的注入到A类中。 用图例来说明一下，先看没有IoC/DI的时候，常规的A类使用C类的示意图，如图：
没有IoC/DI的时候，常规的A类使用C类的示意图
有了IoC/DI的容器后，A类不再主动去创建C了
而是被动等待，等待IoC/DI的容器获取一个C的实例，然后反向的注入到A类中
(5)依赖注入和控制反转是同一概念吗？
根据上面的讲述，应该能看出来，依赖注入和控制反转是对同一件事情的不同描述，从某个方面讲，就是它们描述的角度不同。依赖注入是从应用程序的角度在描述，应用程序依赖容器创建并注入它所需要的外部资源；而控制反转是从容器的角度在描述，容器控制应用程序，由容器反向的向应用程序注入应用程序所需要的外部资源。
4：思想
其实IoC/DI对编程带来的最大改变不是从代码上，而是从思想上，发生了“主从换位”的变化。应用程序原本是老大，要获取什么资源都是主动出击，但是在IoC/DI思想中，应用程序就变成被动的了，被动的等待IoC/DI容器来创建并注入它所需要的资源了。
这么小小的一个改变其实是编程思想的一个大进步，这样就有效的分离了对象和它所需要的外部资源，使得它们松散耦合，有利于功能复用，更重要的是使得程序的整个体系结构变得非常灵活。
工厂方法模式和IoC/DI的关系 他们的思想很类似，都是“主动变被动”，进行“主从换位”，从而获得更灵活的程序结构
平行的类层次结构
（1）什么是平行的类层次结构呢？
简单点说，假如有两个类层次结构，其中一个类层次中的每个类在另一个类层次中都有一个对应的类的结构，就被称为平行的类层次结构。
（2）这种平行的类层次结构用来干什么呢？
主要用来把一个类层次中的某些行为分离出来，让类层次中的类把原本属于自己的职责，委托给分离出来的类去实现，从而使得类层次本身变得更简单，更容易扩展和复用。
（3）工厂方法模式跟平行的类层次结构有何关系呢？
可以使用工厂方法模式来连接平行的类层次。
看上面的示例图，在每个硬盘对象里面，都有一个工厂方法createHDOperate，通过这个工厂方法，客户端就可以获取一个跟硬盘对象相对应的行为对象。然后在硬盘对象的子类中，会覆盖父类的工厂方法createHDOperate，以提供与自身相对应的行为对象，从而自然的把两个平行的类层次连接起来使用。
参数化工厂方法 所谓参数化工厂方法指的就是：通过给工厂方法传递参数，让工厂方法根据参数的不同来创建不同的产品对象 （1）先看代码示例 （2）再体会一下，当需要扩展新的实现 ，使用参数化工厂方法，扩展起来会非常容易
工厂方法模式的优缺点
1：可以在不知具体实现的情况下编程
2：更容易扩展对象的新版本。eg:参数化工厂方法
3：连接平行的类层次
4：具体产品对象和工厂方法的耦合性
思考工厂方法模式
工厂方法模式的本质
工厂方法模式的本质是：延迟到子类来选择实现
简单工厂vs 工厂方法：
具体实现上都是选择实现，简单工厂是直接在工厂类里面进行选择实现；而工厂方法会把这个工作延迟到子类中去实现，工厂类里面使用工厂方法的地方是依赖与抽象而不是具体的实现的，更加灵活，可维护性与可拓展性好。
对设计原则的体现
工厂方法模式很好的体现了“依赖倒置原则” 。 依赖倒置原则告诉我们“要依赖抽象，不要依赖于具体类”，简单点说就是：不能让高层组件依赖于低层组件，而且不管高层组件还是低层组件，都应该依赖于抽象。
何时选用工厂方法模式
1：如果一个类需要创建某个接口的对象，但是又不知道具体的实现，这种情况可以选用工厂方法模式，把创建对象的工作延迟到子类去实现
2：如果一个类本身就希望，由它的子类来创建所需的对象的时候，应该使用工厂方法模式
代码地址： https://gitee.com/weixiaotao1992/DesignPatternsForJava