分组相关常量类

Question

之间的共享。在有效的Java，第17项，乔希布洛赫认为把静态成员入的接口（和实现该接口）是被称为常数接口反模式一种不好的做法：

常量接口模式是接口使用不佳。类 内部使用一些常量是一个 实现细节。 实现 常数接口会导致此 实现细节泄漏到 类的导出API中。对于 类别的用户，该类别实现常量 接口的结果是 。实际上，它甚至可能将它们混淆。更糟糕的是，它代表着一个 的承诺：如果在将来的版本中 类被修改，以至于它不再需要使用 这些常量，它仍然需要实现 接口来保证 的二进制兼容性。如果一个非正式的 类实现了一个常量接口，则其所有子类的接口中的常量 将污染其名称空间的 。

Java平台 库中有几个常量接口，如 java.io.ObjectStreamConstants。这些接口应视为 异常，不应仿效。

我很自信我明白这背后的理由，并完全同意。

我的问题是：在接口与不可实例化的类中分组相关的常量（注意：这些不适用于枚举，考虑相关常量pi和e的数学示例）是一个好主意，提供您只能通过静态引用和静态导入来访问这些值，将隐藏在您的API中的interace保留为默认访问修饰符，并且永远不会实现接口？

为什么或为什么不？除了能够使用私有构造函数以确保常量分组类型从未实例化之外，是否有任何优势将它们归类到类中？

Answer 1

让我们换个方式吧。使用常量接口没有优势。如您所知，接口用于定义合同，而不是常量。我没有看到将interface关键字更改为class关键字和使用public static final字段的问题。使用接口保持常量不是一个好主意。我认为人们使用这种反模式是因为他们不知道静态导入（它是在Java 5.0中引入的），或者他们懒得派发它们的常量在适当的类中。相反，他们只是创建一个接口，让每个类实现它。

编辑：顺便说一句，这个问题听起来像我 - 看看电视，用望远镜看附近的电视机，如果看到的是好的，是不是一个好主意。答案很简单 - 不，望远镜是为其他东西而发明的。啊，我知道这个例子是愚蠢的:)