静态工厂方法代替构造器.docxVIP

第2章 创建和销毁对象本章的主题是创建和销毁对象：何时以及如何创建对象，何时以及如何避免创建对象，如何确保它们能够被适时地销毁，以及如何管理销毁之前必须进行的所有清除动作。第1条：考虑用静态工厂方法代替构造器对于类而言，为了让客户端获取它自身的一个实例，最常用的方法就是提供一个公有的构造器。还有一种方法，也应该成为每个程序员的工具箱中的一部分。类可以提供一个公有的静态工厂方法（static factory method），它只是一个返回类的实例的静态方法。下面是一个来自Boolean（基本类型boolean的包装类）的简单示例。这个方法将boolean基本类型值转换成了一个Boolean对象引用：public static Boolean valueOf(boolean b) {return b ? Boolean.TRUE : Boolean.FALSE;}注意，静态工厂方法与设计模式（Design Patterns）[Gamma95, p.107]中的工厂方法（Factory Method）模式不同。本条目中所指的静态工厂方法并不直接对应于设计模式中的工厂方法。类可以通过静态工厂方法来提供它的客户端，而不是通过构造器。提供静态工厂方法而不是公有的构造器具有两大优势。静态工厂方法与构造器不同的第一大优势在于，它们有名称。如果构造器的参数本身没有确切地描述正被返回的对象，那么具有适当名称的静态工厂会更容易使用，产生的客户端代码也更易于阅读。例如，构造器BigInteger（int, int, Random）返回的BigInteger可能为素数（prime），如果用名为BigIbablePrime的静态工厂方法来表示，显然要好一些。（1.4的发行版本中最终增加了这个方法。）一个类只能有一个带有指定签名的构造器。编程人员通常知道如何避开这一限制：通过提供两个构造器，它们的参数列表只在参数类型的顺序上有所不同。实际上这并不是个好主意。这种API的用户永远也不会记得哪个构造器是哪个，最终会导致调用错误的构造器。人们读到使用了这些构造器的代码时，如果没有参考类的文档，往往不知道这段代码是做什么用的。由于静态工厂方法有名称，所以它们没有像前一段落中所谈到那种限制。如果一个类可能需要多个带有相同签名的构造器时，就用静态工厂方法代替构造器，并且慎重地选择名称以便突出它们之间的区别。静态工厂方法与构造器不同的第二大优势在于，不必在每次调用它们的时候都创建一个新对象。这使得不可变的类（见第15条）可以使用预先构建好的实例，或者将构建好的实例缓存起来，进行重复分发，以避免重复创建不必要的对象。Boolean.valueOf(boolean)方法示范了这种方法：它从来不创建对象。这种方法类似于Flyweight模式[Gamma95，p.195]。如果程序经常请求相同的对象，尤其当创建对象的成本很高时，这种方法可以极大地提升性能。静态工厂方法能够为重复的调用返回相同对象，这样有助于类总能严格控制在某个时刻哪些实例应该存在。这种类被称作实例受控的类（instance-controlled）。编写实例受控的类有几个原因。实例受控使得类可以确保它是一个Singleton（见第3条）或者是不可实例化的（见第4条）。它还使得不可变的类（见第15条）可以确保不会存在两个相等的实例，即当且仅当a==b的时候才有a.equals(b)。如果类保证了这一点，它的客户端就可以使用==操作符来代替equals（Object）方法，这样可以提升性能。枚举（enum）类型（第30条）保证了这一点。静态工厂方法与构造器不同的第三大优势在于，它们可以返回原返回类型的任何子类型的对象。这样我们在选择返回对象的类时就有了很大的灵活性。这种灵活性的一种应用是，API可以返回对象，同时又不会使它们的类变成公有的。以这种方式隐藏实现类会使API变得非常简洁。这种方法适合于基于接口的框架（interface-based framework，见第18条），因为在这种框架中，接口为静态工厂方法提供了自然返回类型。接口不能有静态方法，因此按照惯例，接口Type的静态工厂方法被放在一个名为Types的不可实例化的类（见第4条）中。例如，Java Collections Framework的集合接口有32个便利实现，它们提供了不可修改的集合、同步集合以及类似的东西。几乎所有这些实现都通过静态工厂方法在一个不可实例化的类（java.util.Collections）中导出。所有返回对象的类都是非公有的（nopublic）。现在的Collections Framework API比导出32个独立公有类的那种实现方式要小得多，每种便利实现对应一个类。这不仅仅是指API数量上的减少，也是概念意义上的减少。用户知