第22条：接口只用于定义类型 0f8d30217da248d89e9483a4af4f3f3b.md

第22条：接口只用于定义类型

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

有一种接口被称为常量接口，它不满足上面的条件。这种接口不包含任何方法，它只包含静态的final域，每个域都导出一个常量。使用这些常量的类实现这个接口，以避免用类目来修饰变量名。下面举个例子：

public interface PhysicalConstants {
    static final double AVOGADROS_NUMBER = 6.022_140_857e23;
    
    static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;
    
    static final double ELECTRON_MASS = 9.109_383_56e-31;
}

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

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

如果要导出常量，有几种合理的选择方案。如果这些常量与某个现有的类或者接口紧密相关，就应该把这些常量添加到这个类或者接口中。例如，Java平台类库中的所有数值包装类，如Integer和Double，都导出了MIN_VALUE和MAX_VALUE常量。如果这些常量最好被看作枚举类型的成员，就应该用枚举类型来导出这些常量。否则，应该使用不可实例化的工具类来的导出这次常量。下面的例子就前面的PhysicalConstants例子的工具类翻版：

public class PhysicalConstants {
    private PhysicalConstants() {}
    
    static final double AVOGADROS_NUMBER = 6.022_140_857e23;
    static final double BOLTZMANN_CONSTANT = 1.380_648_52e-23;
    static final double ELECTRON_MASS = 9.109_383_56e-31;
}

注意，有时候会在数字字面量中使用下划线（_）。从Java 7开始，下划线的使用已经是合法的了，他对数字字面量的值没有影响，如果使用得当，还可以极大的提升它们的可读性。如果其中包含五个或五个以上的数字，无论是浮点型还是定点，都要考虑在数字的字面量中添加下划线。对于基数为10的字面量，无论是整数还是浮点，都应该用下划线把数字隔成三位一组，表示一千的正负倍数。

工具类通常要求客户端要用类名类修饰这些常量名，例如PhysicalConstants.AVOGADROS_NUMBER.如果大量利用工具类导出的常量，可以通过利用静态导入机制，避免用类名来修饰常量名：

import static com.kunpeng.demo4.PhysicalConstants.*; //使用static导入

public class Test {
    double atoms(double mols){
        return AVOGADROS_NUMBER * mols;
    }
}

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