接口只用于定义类型，不该该使用常量接口

《Effective Java》中说的感受比较合理，貌似这个问题也是这里提出的，后面那篇是一开始搜到的，也有点用，反正就是不要这么使用就对了。

《Effective Java》第19条：接口只用于定义类型

当类实现接口时，接口就充当能够引用这个类的实例的类型(type)。所以，类实现了接口，就代表客户端能够对这个类的实例实施某些动做（接口中定义的方法）。为了任何其余目的而定义接口是不恰当的。

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

<!-- lang: java -->
// Constant interface antipattern —— do not use!
public interface PhysicalConstants {
  // Avogadro's number (1/mol)
  static final double AVOGADROS_NUMBER   = 6.02214199e23;

  // Boltzmann constant (J/K)
  static final double BOLTZMANN_CONSTANT = 1.3806503e-23;

  ...
}

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

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

若是要导出常量，能够有几种合理的选择方案：

若是这些常量与某个现有的类或者接口紧密相关，就应该把这些常量添加到这个类或者接口中。例如，在Java平台类库中全部的数值包装类，如Integer和Double，都导出了MIN_VALUE和MAX_VALUE常量。

若是这些常量最好被看做枚举类型的成员，就应该用枚举类型(enum type)（见第30条）来导出这些常量。

不然，应该使用不可实例化的工具类(utility class)（见第4条）来导出这些常量。

下面的例子是前面的PhysicalConstants例子的工具类翻版：

<!-- lang: java -->
// Constant utility class
package com.effectivejava.science;

public class PhysicalConstants {
  private PhysicalConstants() { } // Prevents instantiation

  public static final double AVOGADROS_NUMBER   = 6.02214199e23;
  public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
  ...
}

工具类一般要求客户端要用类名来修饰这些常量名。若是大量利用工具类导出的常量，能够经过利用**静态导入(static import)**机制，避免用类名来修饰常量名，不过，静态导入机制是在Java发行版本1.5中才引入的：

<!-- lang: java -->
// 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
}

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

=====

Java Interface（接口） 是常量存放的最佳地点吗？（不是）

因为java interface中声明的字段在编译时会自动加上static final的修饰符，即声明为常量。于是interface一般是存放常量的最佳地点。然而在java的实际应用时却会产生一些问题。

问题的原由有两个，

第一，是咱们所使用的常量并非一成不变的，而是相对于变量不能赋值改变。

例如咱们在一个工程初期定义常量∏＝3.14，而因为计算精度的提升咱们可能会从新定义∏＝3.14159，此时整个项目对此常量的引用都应该作出改变。

第二，java是动态语言。

与c++之类的静态语言不一样，java对一些字段的引用能够在运行期动态进行，这种灵活性是java这样的动态语言的一大优点。也就使得咱们在java工程中有时部份内容的改变不用从新编译整个项目，而只需编译改变的部分从新发布就能够改变整个应用。

讲了这么多，你还不知道我要说什么吗？好，咱们来看一个简单的例子：

有一个interface A，一个class B，代码以下：

<!-- lang: java -->
//file A.java
public interface A {
  String name = "bright";
}
//file B.java
public class B {
  public static void main(String[] args) {
    System.out.println("Class A's name = " + A.name);
  }
}

够简单吧，好，编译A.java和B.java。

运行，输入java B，显然结果以下：

Class A's name = bright

咱们如今修改A.java以下：

<!-- lang: java -->
//file A.java
public interface A{
  String name = "bright sea";
}

编译A.java后从新运行B class，输入java B，注意：结果以下

Class A's name = bright

为何不是Class A's name = bright sea？让咱们使用jdk提供的反编译工具javap反编译B.class看个究竟，输入：javap -c B ，结果以下：

<!-- lang: java -->
Compiled from B.java
public class B extends java.lang.Object {
  public B();
  public static void main(java.lang.String[]);
}
Method B()
  0 aload_0
  1 invokespecial #1 <Method java.lang.Object()>
  4 return
Method void main(java.lang.String[])
  0 getstatic #2 <Field java.io.PrintStream out>
  3 ldc #3 <String "Class A's name = bright">
  5 invokevirtual #4 <Method void println(java.lang.String)>
  8 return

注意到标号3的代码了吗？因为引用了一个static final的字段，编译器已经将interface A中name的内容编译进了class B中，而不是对interface A中的name的引用。所以除非咱们从新编译class B，interface A中name发生的变化没法在class B中反映。若是这样去作那么java的动态优点就消失殆尽。

解决方案，有两种解决方法。

第一种方法是再也不使用常量，将所需字段放入class中声明，并去掉final修饰符。但这种方法存在必定的风险，因为再也不是常量着于是在系统运行时有可能被其余类修改其值而发生错误，也就违背了咱们设置它为常量的初衷，于是不推荐使用。

第二种方法，将常量放入class中声明，使用class方法来获得此常量的值。为了保持对此常量引用的简单性，咱们可使用一个静态方法。咱们将A.java和B.java修改以下：

<!-- lang: java -->
//file A.java
public class A {
  private static final String name = "bright";
  public static String getName() {
    return name;
  }
}
//file B.java
public class B {
  public static void main(String[] args) {
    System.out.println("Class A's name = " + A.getName());
  }
}

一样咱们编译A.java和B.java。运行class B，输入java B，显然结果以下：

Class A's name = bright

如今咱们修改A.java以下：

<!-- lang: java -->
//file A.java
public class A{
  private static final String name = "bright";
  public static String getName(){
    return name;
  }
}

咱们再次编译A.java后从新运行B class，输入java B：结果以下

Class A's name = bright sea

终于获得了咱们想要的结果，咱们能够再次反编译B.class看看class B的改变，输入：

javap -c B,结果以下：

<!-- lang: java -->
Compiled from B.java
public class B extends java.lang.Object {
  public B();
  public static void main(java.lang.String[]);
}
Method B()
   0 aload_0
   1 invokespecial #1 <Method java.lang.Object()>
   4 return
Method void main(java.lang.String[])
   0 getstatic #2 <Field java.io.PrintStream out>
   3 new #3 <Class java.lang.StringBuffer>
   6 dup
   7 invokespecial #4 <Method java.lang.StringBuffer()>
  10 ldc #5 <String "Class A's name = ">
  12 invokevirtual #6 <Method java.lang.StringBuffer append(java.lang.String)>
  15 invokestatic #7 <Method java.lang.String getName()>
  18 invokevirtual #6 <Method java.lang.StringBuffer append(java.lang.String)>
  21 invokevirtual #8 <Method java.lang.String toString()>
  24 invokevirtual #9 <Method void println(java.lang.String)>
  27 return

注意标号10至15行的代码，class B中已经变为对A class的getName()方法的引用，当常量name的值改变时咱们只需对class A中的常量作修改并从新编译，无需编译整个项目工程咱们就能改变整个应用对此常量的引用，既保持了java动态优点又保持了咱们使用常量的初衷，于是方法二是一个最佳解决方案。