在Effective Java，第17项中，Josh Bloch认为将静态成员放入接口（并实现该接口）是一种不好的做法，称为常量接口反模式：
常量接口模式是接口的不良使用。那一堂课 内部使用一些常量是一个 实施细节。 实施 常量接口导致此 实施细节泄漏到 class的导出API。没有 对班级用户的影响 该类实现了一个常量 接口。事实上，它甚至可能 混淆他们。更糟糕的是，它代表了一个 承诺：如果在将来发布 类被修改，以便它不再 需要使用常量，它仍然 必须实现接口以确保 二进制兼容性如果是非最终的 class实现一个常量接口， 它的所有子类都有它们的 被常量污染的名称空间 在界面中。
java平台中有几个常量接口 图书馆，如
java.io.ObjectStreamConstants。这些 接口应该被视为 异常，不应该被模仿。
我很自信我理解这背后的理由并完全同意。
我的问题是：分组相关常量（注意：这些不适合枚举，考虑相关常量pi和e的数学示例）在接口与非可实例化类中是一个好主意，如果你只通过静态引用和静态导入来访问这些值，那么使用默认的访问修饰符保持从API隐藏的interace，并且永远不会实际实现接口？
为什么或为什么不呢？除了能够使用私有构造函数以确保永远不会实例化常量分组类型之外，是否有任何优势可以将它们分组到类中？
答案 0 :(得分：2)
让我们换一种方式。使用常量接口没有任何优势。如您所知，接口用于定义合同，而不是用于常量。我没有看到将interface关键字更改为class关键字并使用public static final字段的问题。使用接口来保持常量绝不是一个好主意。我认为人们使用这种反模式是因为他们不了解静态导入（它是在Java 5.0中引入的），或者他们懒得在适当的类中调度它们的常量。相反，他们只创建一个接口，让每个类实现它。
编辑：顺便说一下这个问题听起来像 - 看电视，用望远镜看邻居的电视是个好主意，前提是视线很好。答案很简单 - 不，望远镜是为其他东西发明的。啊，我知道这个例子很愚蠢：）