在之前的文章中介绍了设计模式中最简单的一种，传送门：设计模式之单例模式。今天再来介绍另外一种比较常见的工厂方法模式，他是对象模式三剑客建设者模式 工厂方法模式 抽象工厂模式之一。
在介绍工厂方法模式之前，先介绍一种简单的模式：简单工厂模式：它属于创建型模式，又叫做静态工厂方法（Static Factory Method）模式。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式，可以理解为是不同工厂模式的一个特殊实现。但是它并不属于23中GOF设计模式中的一种，它只是工厂方法的基础。
1、简单工厂模式
在介绍简单工厂之前，先自己写一个功能。假设咱们现在要实现一个计算器例子，为了实现各算法之间的解耦，先定义一个抽象的Calculator类：
其中定义了一个方法getResult();这个方法由其子类来重写返回值；下面写一个add 的类其他类似：
下面测试方法：
可以看到当我需要执行加法运算时，我就要创建一个CalculatorAdd类。如果是减法那么我就要创建一个CalculatorSub类以此类推.....
也就是说，我想要使用不同的运算的时候就要创建不同的类，并且要明确知道该类的名字。
那么这种重复的创建类的工作其实可以放到一个统一的工厂类中---简单工厂。
定义一个工厂类负责生产产品：
这样一个简单工厂，调用者只需要知道一个type 操作就可以得到相应的对象”：
可以看到这样确实优化了很多，但是由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建对象的逻辑集中放到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。
当系统中的具体类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求．这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利；这个时候工厂方法模式就比较好了。
2、工厂方法模式
工厂方法模式(Factory Method Pattern)又称为工厂模式，也叫虚拟构造器(Virtual Constructor)模式或者多态工厂(Polymorphic Factory)模式，它属于类创建型模式。
这里还用计算器的例子。在保持Calculator，CalculatorAdd，CalculatorDiv，CalculatorSub，CalculatorMul等几个方法不变的情况下，修改简单工厂模式中的工厂类（CalculatorFactory）。替代原有的那个”万能”的大工厂类，这里使用工厂方法来代替：
这样，在客户端中想要执行加法运算时，需要以下方式：
工厂方法模式是简单工厂模式的进一步抽象和推广。
工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不负责产品类被实例化这种细节，这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。
工厂方法模式的主要优点是增加新的产品类时无须修改现有系统，并封装了产品对象的创建细节，系统具有良好的灵活性和可扩展性；其缺点在于增加新产品的同时需要增加新的工厂，导致系统类的个数成对增加，在一定程度上增加了系统的复杂性。
