我同意使用界面不是正确的方法。在Bloch的《Effective Java》中，避免这种模式甚至有自己的项目(#18)。

Bloch反对常量接口模式的一个论点是，常量的使用是一个实现细节，但是实现一个使用它们的接口会在导出的API中暴露该实现细节。

public|private static final TYPE NAME = VALUE;模式是一种声明常数的好方法。就我个人而言，我认为最好避免创建一个单独的类来存放所有的常量，但除了个人偏好和风格之外，我还没有看到不这样做的理由。

如果常量可以很好地建模为枚举，请考虑1.5或更高版本中可用的枚举结构。

如果您使用的是1.5以前的版本，您仍然可以通过使用普通的Java类来实现类型安全枚举。(详见这个网站)。

那么枚举呢?

更进一步，您可以将全局使用的常量放在接口中，这样它们就可以在系统范围内使用。如。

public interface MyGlobalConstants {
    public static final int TIMEOUT_IN_SECS = 25;
}

但是不要执行它。只需在代码中通过完全限定类名直接引用它们。

我同意大多数人所说的，在处理常量集合时最好使用枚举。然而，如果你在Android上编程，有一个更好的解决方案:IntDef Annotation。

@Retention(SOURCE)
@IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS})
public @interface NavigationMode {}
public static final int NAVIGATION_MODE_STANDARD = 0;
public static final int NAVIGATION_MODE_LIST = 1;
public static final int NAVIGATION_MODE_TABS = 2;
...
public abstract void setNavigationMode(@NavigationMode int mode);
@NavigationMode
public abstract int getNavigationMode();

IntDef注释在一个简单的方面优于枚举，它占用的空间明显更少，因为它只是一个编译时标记。它不是一个类，也没有自动字符串转换属性。

在单独的类中创建静态final常量可能会给您带来麻烦。Java编译器实际上会对此进行优化，并将常量的实际值放置到引用它的任何类中。

如果你稍后更改了Constants类，并且没有对引用该类的其他类进行严格的重新编译，那么你最终将使用新旧值的组合。

不要把它们看作常量，而应该把它们看作配置参数，并创建一个类来管理它们。让值是非final的，甚至可以考虑使用getter。将来，当您确定其中一些参数实际上应该由用户或管理员进行配置时，这将变得容易得多。

在Effective Java(第二版)中，建议对常量使用枚举而不是静态整型。

这里有一篇很好的关于Java中枚举的文章: http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

请注意，在那篇文章的最后提出的问题是:

那么什么时候应该使用枚举呢?

答案为:

任何时候你需要一个固定的常数集