Scala设计模式Part I. 创建模式——3.工厂方法

描述

工厂方法的意图是：
定义一个对象创建接口，但是让子类决定实例化哪个类。工厂方法让类的实例化延迟到子类。

工厂方法通常用于实例化时无法确定其类型的情况。GOF中以一个应用程序框架为例。抽象应用程序类具备创建文档的功能。框架的用户根据具体的应用特性继承抽象文档类。框架的设计者无法确定具体确定应用类最终创建的是哪个文档类的子类，因为用户可以自由扩展文档类。为此应用类提供一个用于工厂方法，它返回抽象文档类的某个子类实例。工厂方法可以由应用程序类的子类通过重载工厂方法进行精确实现。

在下图中以上例子中的文档类扮演产品（Product）的角色，文档的具体实现是图中的具体产品（Concrete Product）。产品的创建者是应用类。框架用户指定的具体应用类对应图中的Concrete Creator。

分析

通过创建Creator的子类来创建新的product不是因为Creator必须被子类化，这引出了设计中必须处理的另一个关键点。
参数化的工厂方法有助于保证对子类型的最小需求。依赖于不同的实现，这也许会缺少子类型中安全的静态属性。
工厂方法本质上移除了具体产品类与创建类之间的依赖关系，从而使得产品的创建多样化。
抽象类型可以表达这一需求，如下代码所示：

trait Document {
  def open
  def close
}

trait Application {
  type D<:Document
  var docs=List[D]()
  def newDocument= {
    val doc=new D
    docs=doc::docs
    doc.open
  }
}

Document特质是抽象产品的角色，Application是创建者的角色。抽象类型成员 type D<:Document 明确的声明了应用特质依赖于Document的子类型。newDocument方法试图创建一个D类型的实例。Scala编译器会报错，“class type required but Application.this.D found”。这一次错误有多个原因，例如具体类型应是另一个扩展了Document特质的类型，并且Scala中特质是不能实例化的。在Scala中无法约束构造器中的某个类型是类类型。
所以我们被迫使用初始方案中的工厂方法。

模块化

Scala的解决方案中没有样板代码，所以不能进行模块化。可以尝试用高阶工厂函数表示一个可重用的特质。当使用该特质时，传入一个创建函数和所需的参数。创建方法需要数量不同、类型不同的参数，但是无法对此进行抽象。任何创建方法只有固定数量的参数，这限制了方法的重用性。结论是模块化无法实现，因为scala缺少所需的抽象机制。

Scala的解决方案

trait Document {
  def open
  def close
}

trait Application {
  type D<:Document
  var docs=List[D]()

  def newDocument= {
  val doc=createDocument
  docs=doc::docs
  doc.open
}

  //工厂方法
  def createDocument:D
}

Scala使用抽象类型比初始方案有很多优势。这为重用子类型提供了方便。我们可以在Application特质中使用泛型集合和方法，同时Application的子类没有丢失类型信息。这一模式的意图非常清楚，Application类依赖于Document的某个实现版本。无需为每个产品类命名，scala的混入组合（mixin composition）特性为此提供了一个实现的捷径。