工厂方法模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。
产生：说到工厂模式，我想大家就能想到简单工厂模式，由于在简单工厂模式中当需要扩展功能时就需要修改原类，这违背了开放-封闭原则，而工厂方法模式则将类的实例化延迟到子类，避免了类的修改，下面是两种模式结构图：
1、简单工厂模式结构图：
1) 工厂类角色（Creator）：这是本模式的核心，含有一定的商业逻辑和判断逻辑。
2) 抽象产品角色(Product)：它一般是具体产品继承的父类或者实现的接口。
3) 具体产品角色(ConcreteProduct)：工厂类所创建的对象就是此角色的实例。
2、工厂方法模式结构图：
1) 抽象工厂角色()Creator)： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。
2) 具体工厂角色(ConcreteCreator)：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。
3) 抽象产品角色(Product)：它是具体产品继承的父类或者是实现的接口。
4) 具体产品角色(ConcreteProduct)：具体工厂角色所创建的对象就是此角色的实例。
实例引用：
用一个大家比较熟知的故事来介绍工厂方法模式：女娲补天，
分析：首先对造人过程进行分析，该过程涉及三个对象：女娲、八卦炉、三种不同肤色的人，女娲可以使用场景类Client来表示，八卦炉类似于一个工厂，负责制造生产产品（即人类）：三种不同肤色的人，他们都是同一个接口下的不同实现类，都是人嘛，只是肤色、语言不同，对于八卦炉来说都是它生产出的产品。
解释：类图比较简单，AbstractHumanFactory是一个抽象类，定义了一个八卦炉都具有的整体功能，HumanFactory为实现类，完成具体的任务：创建人类；Human接口是人类的总称，其三个实现类分别为三类人种；NvWa类是一个场景类，负责模拟这个场景，执行相关的任务。
理解：结合例子，我们知道工厂方法实现时，客户端需要决定实例化哪个工厂来实现运算类，选择判断的问题还是存在的，也就是说，工厂方法模式把简单工厂的内部逻辑判断移到了客户端代码来进行，你想加功能，本来是改工厂类，而现在是改客户端。
结合之前对工厂模式的介绍，这个例子就自然而然很清楚啦！
