用户工具

站点工具


book:第1条_考虑用静态工厂方法代替构造器

(WIP)

1 问题与常规方案

问题

对于某个类,想让客户端能获取它的实例。

常规方案

提供一个公有构造器。

2 推荐方案

提供一个公有的静态工厂方法,它只是一个返回类的实例的静态方法。 下面是一个来自 Boolean 的例子:

public static Boolean valueOf(boolean b) {
    return b ? Boolean.TRUE : Boolean.FALSE;
}

3 推荐理由

提供静态工厂方法而不是公有的构造器,有几大优势:

  1. 它们有名称。更容易理解和使用,客户端代码的可读性更好。
  2. 不必在每次调用它们的时候都创建一个新对象。(提升性能;编写实例受控的类)
  3. 它们可以返回原返回类型的任何子类型的对象。这样我们在选择返回对象的类时就有了更大的灵活性。(以 java.util.Collections 为例)
  4. 在创建参数化类型实例的时候,它们使代码变得更加简洁。

4 缺点与措施

5 其他阅读收获

好习惯

  • 当一个类需要多个带有相同签名的构造器时,就用静态工厂方法代替构造器,并且慎重地选择名称以便突出它们之间的区别。

坏习惯

  • 一个类只能有一个带有指定签名的构造器。编程人员通常知道如何避开这一限制:通过提供两个构造器,它们的参数列表只在参数类型的顺序上有所不同。实际上这并不是个好主意。面对这样的 API,用户永远也记不住该用哪个构造器,结果常常会调用错误的构造器。并且,读到使用了这些构造器的代码时,如果没有参考类的文档,往往不知所云。
book/第1条_考虑用静态工厂方法代替构造器.txt · 最后更改: 2020/09/02 08:58 由 plough