Effective Java 第三版读书笔记——条款 22:接口应该只被用于定义类型
当类实现接口时,该接口会作为一种类型(type),可以被用来引用类的实例。因此,一个类实现了一个接口,就是表明客户端可以对这个类的实例做些什么。为其他目的定义接口是不合适的。
一种失败的接口就是所谓的常量接口(constant interface)。这样的接口不包含任何方法;它只包含静态 final 属性,每个属性输出一个常量。使用这些常量的类实现这个常亮接口,以避免需要用类名限定常量名。这里是一个例子:
// Constant interface antipattern - do not use!
public interface PhysicalConstants {
// Avogadro's number (1/mol)
static final double AVOGADROS_NUMBER = 6.022_140_857e23;
// Boltzmann constant (J/K)
static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;
// Mass of the electron (kg)
static final double ELECTRON_MASS = 9.109_383_56e-31;
}
常量接口模式是对接口的糟糕使用。类在内部使用一些常量,完全属于实现细节。实现一个常量接口会导致这个实现细节泄漏到类的导出 API 中。对类的用户来说,类实现一个常量接口是没有意义的。更糟糕的是,它代表了一个承诺:如果在将来的版本中修改了类,不再需要使用常量,那么它仍然必须实现接口,以确保二进制兼容性。如果一个非 final 类实现了常量接口,那么它的所有子类的命名空间都会被接口中的常量所污染。Java 平台类库中有多个常量接口,如 java.io.ObjectStreamConstants
。这些接口应该被视为不规范的,不应该被效仿。
如果你想导出常量,有几个合理的选择方案。如果常量与现有的类或接口紧密相关,则应将其添加到该类或接口中。例如,所有数字基本类型的包装类,如 Integer
和 Double
,都会导出 MIN_VALUE
和 MAX_VALUE
常量。如果常量最好被看作枚举类型的成员,则应该使用枚举类型(条款 34)导出它们。 否则,你应该用一个不可实例化的工具类来导出常量(条款 4)。这里是前面所示的 PhysicalConstants
示例的工具类的版本:
// Constant utility class
package com.effectivejava.science;
public class PhysicalConstants {
private PhysicalConstants() { } // Prevents instantiation
public static final double AVOGADROS_NUMBER = 6.022_140_857e23;
public static final double BOLTZMANN_CONST = 1.380_648_52e-23;
public static final double ELECTRON_MASS = 9.109_383_56e-31;
}
顺便提一下,请注意在数字文字中使用下划线字符(_)。从 Java 7 开始,下划线对数字字面量的值没有影响,但是如果使用得当的话可以使它们更容易阅读。如果浮点数包含五个或更多的连续数字,考虑将下划线添加到数字字面量中。
通常,实用工具类要求客户端使用类名来限定常量名,例如 PhysicalConstants.AVOGADROS_NUMBER
。 如果大量使用实用工具类导出的常量,则可以通过使用静态导入来避免类名的限定:
// Use of static import to avoid qualifying constants
import static com.effectivejava.science.PhysicalConstants.*;
public class Test {
double atoms(double mols) {
return AVOGADROS_NUMBER * mols;
}
...
// Many more uses of PhysicalConstants justify static import
}
总之,接口应该只被用于定义类型。它们不应该用于导出常量。
上一篇: OpenGL:应用纹理的四个步骤以及纹理坐标的几何变换
下一篇: Kotlin探究之旅-基础篇