当类实现接口时,接口就可以充当引用这个类的实例的类型(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。这些接口应该被认为是反面的典型,不值得效仿。
如果要导出常量,可以有几种合理的选择方案。如果这些常量与某个现有的类或者接口紧密相关,就应该把这些常量添加到这个类或者接口中。例如,在Java平台类库中所有的数值包装类,如Integer和Double,都导出了MIN_VALUE和MAX_VALUE常量。如果这些常量最好被看做枚举类型的成员,就应该用枚举类型(enum type)(第34项)。否则,应该使用不可实例化的工具类(utility class)(第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。如果大量利用工具类导出的常量,可以通过利用静态导入(static import)机制,避免用类名来修饰常量名:
// 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
}
简而言之,接口应该只被用来定义类型,他们不应该被用来导出常量。