工厂方法一直不懂它的价值，虽然知道它的形式。今天《iOS设计模式解析》+这篇回答突然茅塞顿开。基于我的理解重新解释一下。
首先构建一下背景
对于一个模块而言，它提供服务，服务的具体内容外界是不知道的，如餐厅提供吃饭的服务，具体菜是怎么做出来的外界是不知道的（因为分工需要，不可能每件事都知道）。这里服务就是接口interface，具体服务内容就是实现implematation。
然后一个接口可能对应多个服务，同样是“点菜”，不同的菜区别很大、同一个菜不同的厨师、不同的餐厅区别也很大。所以这里就存在一系列的区别因素，这些因素共同决定了这个接口到底会选择什么样的实现。
所以你会发现从接口到实现之间的关联是有一个逻辑判断的，而工厂方法就是这个逻辑判断，只是这是服务就是“创建一个对象”。
工厂方法只是特例应用
我现在要创建一个对象，但是我只有一些区别因素，比如造车，我只知道颜色、类别等，基于这些因素如何创建对象的逻辑，我把它写到一个统一的方法里，它就是工厂方法。
这么做的好处是：
- 这个逻辑判断谁更清楚？创建者还是调用者？肯定是创建者，是它提供了创建对象的服务。
- 使用统一的方法，可以保证判断逻辑的统一，如果以后要修改这个逻辑，只需要修改一处就可以了。
想象一下不使用工厂方法会怎么做：
- 每个构建的地方我都来一遍逻辑判断，写上N个
if-else，然后需求一变，每个地方都要改 - 每个构建的地方，我都知道具体要哪个对象，我不需要做判断，直接指定需要的对象构建。如果这个对象是另一个模块的，这么做就相当于把构建选择的逻辑掺杂到里当前的模块里，甚至更明显的，那个模块是另一个部分做的，需求变了以后两个部门都要改代码，这就会比较乱了。
而使用工厂方法，只要这个方法的声明不变，那么使用者就不要修改代码，需求改变了也只是创建模块这边修改。
就像造车（构建对象），我想要一个红色的大空间的越野车（区别因素），我把需求提交给工厂，工厂给我车。至于工厂怎么造车的，造了什么车我是不知道的我也不关心，只要我的需求达到了就可以了。
最核心的问题，目光不要放到创建对象这个事情本身，而是从外界需求到对象选择之间的这个逻辑身上，还有构建一个统一方法把逻辑流统一的这个出发点上。工厂方法只是“接口+N个实现”的这种模型在“构建对象”上的一个特例而已，它的核心意义并不在“构建对象”这个是事情本身上。
发散
从这个设计上看，我觉得它可以理解为是“面向接口编程”理念的一个子集。而更广泛的模型是：一个接口，有N个实现，外界提供一些区别因素，接口就像是大门，实现就像是大门里的小门，区别因素从大门流入，走进不同的小门。除了工厂模式，还有很多的地方也会这么做。
