简单工厂


抽象了多种对象的创建实现(具体过程) (在 简单工厂 中, 通过 描述信息, 创建对应 对象)

缺陷:

  • 多种对象的创建实现,耦合在了一个简单工厂中

工厂方法


抽象了 每种对象的创建实现

优点

  • 解决了 简单工厂, 主要问题.

应用中有两种使用思路:

(在 简单工厂 中, 通过 描述信息, 选用对应的 工厂方法 创建 对应对象)

缺陷

  • 简单工厂由 原来对 多种对象的创建实现的耦合, 转变为了 对多个具体工厂的耦合
  • 本质上没有解决耦合的问题, 只是简化了耦合的复杂对[由多种对象的创建实现 -> 多种具体工厂]

(通过 描述信息, 选用对应的 工厂方法 创建 对应对象)

缺陷

相比于前一种, 将耦合在简单工厂具体工厂实现分散在了具体调用处, 去除了多个具体工厂耦合的问题

  • 然而引入了一个新的问题, 暴露过多接口信息(具体工厂)

抽象工厂


抽象统一了 对象创建 的入口, 不管实现为通过 简单工厂 还是具体工厂 创建

优点

  • 简化了暴露在外部的接口信息

存在的问题

  • 需要简化接口信息
  • 需要要保证创建对象行为的多样性

内部实现的复杂度难度会大大提升.

需要的扩展(特性)

  • 简化接口信息(特性) 需要 使用到 原型模式,建造者模式之类, 扩展需要创建对象的描述信息
  • 对象复用(特性) 需要 使用到 享元模式, 实现对象的缓存复用

总结


单一实现到抽象工厂一级的话, 基本上还是不能很好的解决代码的耦合问题, 基本上还需要加上其他的模式辅助, 这样才能让其成为解耦神器(解耦接口统一), 即多种模式复合(抽象工厂 + 工厂方法 + 原型 + 享元).

当然高度的抽象同时也代表着学习曲线的提升.(Spring BeanFactory, Typhoon, AngularJS Inject)可以充分证明这一点.