接口只用于定义类型

接口只用于定义类型

当类实现接口时，接口就充当可以引用这个类的实例的类型（type）。因此，类实现了借口，就表明客户端可以对这个类的实例实施某些动作。为了任何其他目的而定义接口是不恰当的。

有一种接口被称为常量接口（constant interface），亚布妈祖上面的条件。这种接口没有包含任何方法，它只包含静态的final域，每个域都导出一个常量。使这些常量的类实现这个借口，以避免类名来修饰常量名。

// Constant interface antipattern - do not use
public interface PhysicalConstants{
  // Avogadro's number
  static final double AVOGADROS_NUMBER = 6.02214199e23;
  // Boltzmann constant
  static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
  //Mass of the electron
  static final double ELECTRON_MASS = 9.109381883-31;
}

常量接口模式是对接口的不良使用。类在内部使用某些变量，这纯粹是实现细节。实现常量接口，这会导致把这样的实现细节泄漏到该类的导出API中。类实现常量接口，这对于这个类的用户来讲并没有什么价值。实际上，这样做反而会使他们更加糊涂。更糟糕的是，它代表着一种承诺：如果将来版本中，这个类被修改了，它将不再需要这些常量了，它依然必须实现这个接口，以确保二进制兼容性。如果非final类实现了常量接口，它的所有类的命名空间也会被接口中的常量所“污染”。

在Java平台类库中有几个常量接口，例如java.io.ObjectStreamConstants。这些接口应该被认为反面的典型，不值得效仿。

如果到出常量，可以有集中合理的选择方案。如果这些常量与某个相关的类或者接口紧密相关，就应该把这些常量添加到这个类或者接口中。例如Java平台类库中所有的数值包装类，如Integer和Double，都导出了MIN_VALUE和MAX_VALUE常量。如果这些常量被看成枚举类型的成员，就应该用枚举类型（enum type）来导出这些常量。否则应该使用不可实例化的工具类来导出这些常量。

// Constant utility class
public class PhysicalConstants{
  private PhysicalConstants(){}
  // Avogadro's number
  public static final double AVOGADROS_NUMBER = 6.02214199e23;
  // Boltzmann constant
  public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
  //Mass of the electron
  public static final double ELECTRON_MASS = 9.109381883-31;
}

工具类通常要求客户端要用类名来修饰这些常量名，例如PhysicalConstants.AVOGADROS_NUMBER。如果大量利用工具类导出的常量，可以通过利用静态导入（static import）机制，避免用类名来修饰常量名，不过静态导入机制是Java发行版本1.5中才引入的。

简而言之，接口应该只被用来定义类型，他们不应该被用来导出常量。