对“工厂方法”，忽然茅塞顿开

工厂方法一直不懂它的价值，虽然知道它的形式。今天《iOS设计模式解析》+这篇回答忽然茅塞顿开。基于个人理解从新解释一下。

首先构建一下背景

对于一个模块而言，它提供服务，服务的具体内容外界是不知道的，如餐厅提供吃饭的服务，具体菜是怎么作出来的外界是不知道的（由于分工须要，不可能每件事都知道）。这里服务就是接口interface，具体服务内容就是实现implematation。

而后一个接口可能对应多个服务，一样是“点菜”，不一样的菜区别很大、同一个菜不一样的厨师、不一样的餐厅区别也很大。因此这里就存在一系列的区别因素，这些因素共同决定了这个接口到底会选择什么样的实现。

因此你会发现从接口到实现之间的关联是有一个逻辑判断的，而工厂方法就是这个逻辑判断，只是这是服务就是“建立一个对象”。

工厂方法只是特例应用

我如今要建立一个对象，可是我只有一些区别因素，好比造车，我只知道颜色、类别等，基于这些因素如何建立对象的逻辑，我把它写到一个统一的方法里，它就是工厂方法。

这么作的好处是：

1. 这个逻辑判断谁更清楚？建立者仍是调用者？确定是建立者，是它提供了建立对象的服务。
2. 使用统一的方法，能够保证判断逻辑的统一，若是之后要修改这个逻辑，只须要修改一处就能够了。

想象一下不使用工厂方法会怎么作：

1. 每一个构建的地方我都来一遍逻辑判断，写上N个if-else，而后需求一变，每一个地方都要改
2. 每一个构建的地方，我都知道具体要哪一个对象，我不须要作判断，直接指定须要的对象构建。若是这个对象是另外一个模块的，这么作就至关于把构建选择的逻辑掺杂到里当前的模块里，甚至更明显的，那个模块是另外一个部分作的，需求变了之后两个部门都要改代码，这就会比较乱了。

而使用工厂方法，只要这个方法的声明不变，那么使用者就不要修改代码，需求改变了也只是建立模块这边修改。

就像造车（构建对象），我想要一个红色的大空间的越野车（区别因素），我把需求提交给工厂，工厂给我车。至于工厂怎么造车的，造了什么车我是不知道的我也不关心，只要个人需求达到了就能够了。

最核心的问题，目光不要放到建立对象这个事情自己，而是从外界需求到对象选择之间的这个逻辑身上，还有构建一个统一方法把逻辑流统一的这个出发点上。工厂方法只是“接口+N个实现”的这种模型在“构建对象”上的一个特例而已，它的核心意义并不在“构建对象”这个是事情自己上。

发散

从这个设计上看，我以为它能够理解为是“面向接口编程”理念的一个子集。而更普遍的模型是：一个接口，有N个实现，外界提供一些区别因素，接口就像是大门，实现就像是大门里的小门，区别因素从大门流入，走进不一样的小门。除了工厂模式，还有不少的地方也会这么作。