阅读 13

对“工厂方法”,突然茅塞顿开

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

首先构建一下背景

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

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

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

工厂方法只是特例应用

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

这么做的好处是:

  1. 这个逻辑判断谁更清楚?创建者还是调用者?肯定是创建者,是它提供了创建对象的服务。
  2. 使用统一的方法,可以保证判断逻辑的统一,如果以后要修改这个逻辑,只需要修改一处就可以了。

想象一下不使用工厂方法会怎么做:

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

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

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

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

发散

从这个设计上看,我觉得它可以理解为是“面向接口编程”理念的一个子集。而更广泛的模型是:一个接口,有N个实现,外界提供一些区别因素,接口就像是大门,实现就像是大门里的小门,区别因素从大门流入,走进不同的小门。除了工厂模式,还有很多的地方也会这么做。

关注下面的标签,发现更多相似文章
评论