book:第1条_考虑用静态工厂方法代替构造器
(WIP)
1 问题与常规方案
问题
对于某个类,想让客户端能获取它的实例。
常规方案
提供一个公有构造器。
2 推荐方案
提供一个公有的静态工厂方法,它只是一个返回类的实例的静态方法。 下面是一个来自 Boolean 的例子:
public static Boolean valueOf(boolean b) { return b ? Boolean.TRUE : Boolean.FALSE; }
3 推荐理由
提供静态工厂方法而不是公有的构造器,有几大优势:
- 它们有名称。更容易理解和使用,客户端代码的可读性更好。
- 不必在每次调用它们的时候都创建一个新对象。(提升性能;编写实例受控的类)
- 它们可以返回原返回类型的任何子类型的对象。这样我们在选择返回对象的类时就有了更大的灵活性。(以 java.util.Collections 为例)
- 在创建参数化类型实例的时候,它们使代码变得更加简洁。
4 缺点与措施
5 其他阅读收获
好习惯
- 当一个类需要多个带有相同签名的构造器时,就用静态工厂方法代替构造器,并且慎重地选择名称以便突出它们之间的区别。
坏习惯
- 一个类只能有一个带有指定签名的构造器。编程人员通常知道如何避开这一限制:通过提供两个构造器,它们的参数列表只在参数类型的顺序上有所不同。实际上这并不是个好主意。面对这样的 API,用户永远也记不住该用哪个构造器,结果常常会调用错误的构造器。并且,读到使用了这些构造器的代码时,如果没有参考类的文档,往往不知所云。
book/第1条_考虑用静态工厂方法代替构造器.txt · 最后更改: 2020/09/02 16:58 由 plough