最终结论：定义常量在interface和class中其实都行，关键是看你的设计和个人爱好。
Java中interface中定义变量默认都是"public static final"类型的，也就是常量，因此很多人在interface定义常用的常量。
下面是功能等同的两种定义常量的方式:
class：
package com.example;
public final class Constants {
private Constants() {}
public static final int A = 100;
public static final int B = 100;
public static final int C = 100;
public static final int D = 100;
}
interface：
package com.example;
public interface Constants {
int A = 100;
int B = 100;
int C = 100;
int D = 100;
}
类定义常量和接口定义常量:
1、类定义常量，需要定义成final且定义一个private的构造方法，这样做是为了不让其他类继承，禁止实例化此类，调用时直接以"类.常量"的方式调用。
2、接口中定义的"变量"，其实就是常量，接口中的"变量"默认都是 "public static final"类型，即为常量，因此接口可以省略"public static final"而直接写成 "type variable"。
3、用如上的类定义常量，不能实例化也不能被继承，看起来完美无缺。
4、接口定义常量，虽不能实例化，确可以被其他类实现；
因此有这么一种设计模式"The constant interface pattern". 所谓的"常量接口模式"， 就是其他类要使用接口中定义的常量，就实现该接口. 我认为这是对接口的烂用. 接口中定义的常量应为所有类频繁使用的常量，但并不是每个类都使用了接口中定义的所有常量，因而导入了不必要的常量到这个类中，并且导入后这个类的子类也会基础导入的常量，这样会导致混乱，应当避免此种用法。
5、在interface和class中定义相同的常量，interface生成的class文件比class生成的class文件会更小，而且更简洁，效率更高。可以使用jad和javap反编译去分析一下。
个人总结：
1、不要使用"常量接口模式"，此模式会导致类中的常量混乱，增加维护难度。注意！是常量接口模式时不要使用，而对于普通的设计是可以使用接口去实现的。
2、不要使用静态导入，import static *****，因为import static会导致可维护性下降，维护的人看代码时，不是那么清楚或者不那么迅速的知道这个常量位于哪个文件中。建议使用常量的地方直接 "接口.常量名" 的方式使用。
3、还有用这种方式定义常量: public abstract class Constants {}，很容易看出这种方式定义常量的目的：禁止实例化。但是"abstract class"的目的是为了让其他类继承，因此语意别扭，同样具有interface定义常量的确定，即可以被继承， 其实解决上述问题更优美的方式是用final修饰类并给类定义一个private构造方法。
4、对于用是用interface定义常量还是使用class定义常量，看个人喜好. 个人觉得interface定义常量更为优美：代码更简洁， 生成的class文件更小，JVM不要考虑类的附加特性，如方法重载等，因而更为高效。这是一种反模式的用法，很多人不喜欢这种用法，如果我们知道它的优缺点，延长避短，也是无可厚非的，还有一点是不要把这种用法用成"常量接口模式"，个人觉得"常量接口模式"确实是一种对interface的"pool use"。
