最近我遇到了一段代码，其中我找到了一个只有 常量的界面。并且使用静态导入在类中访问这些常量。常数更多（约30至50）。
就个人而言，我认为这不是一个好习惯。这就是为什么它根据Effective Java被称为Constant Interface Antipattern。我没有找到任何理由去进行这种编码。
此外，仅当我们的应用程序中的许多类导入的常量很少时，才应使用静态导入。
如果有任何其他充分的理由可以选择常量界面，请有人告诉我吗？
答案 0 :(得分：5)
当然，在引入枚举之前，如果你需要在许多类之间共享大量常量，那么Constant Interface可能是最实用的方法。
如果这些常量仅在一个类中使用，那么其他答案中的注释（“要避免的模式”）是非常有效的 - 如果由使用它们的类声明它们将是最有用的。
对于较新版本的Java，我将使用允许设置值的构造函数转向枚举。但是仍然如此，如果这组值仅由一个类使用，那么在该类中而不是单独声明它们是最有意义的。
答案 1 :(得分：3)
如果这些常量进行了一些逻辑分组，那么我可以使用枚举代替
答案 2 :(得分：2)
我根本不喜欢这个习语。为什么要将常量与使用它们的上下文分开？我觉得这很令人困惑。
这个设计强制一个类需要一个常量来实现一个充满它们的整个接口。所有这些常数都是公开的。
enum的想法很好。除此之外的任何东西。
答案 3 :(得分：1)
常见的替代方法是在实用程序类而不是接口中定义公共静态最终常量。获取常量接口，将其重新定义为类，在每个声明上放置“public static final”，并引用由类名限定的变量，而不是通过实现接口。
我倾向于认为一组常量与枚举不同。
答案 4 :(得分：0)
这个链接有一个有效的讨论http://www.theserverside.com/discussions/thread.tss?thread_id=19221
并且最重要的是尽可能避免使用常量接口
答案 5 :(得分：0)
这个解决方案不是很好，但有时候是将所有常量聚集在一个地方的最佳选择，例如应用程序中使用的翻译键。
使用接口我们可以创建这些接口的整个存储，而不是复制它们。
答案 6 :(得分：0)
完全没有。我会尽可能避免这种模式，在我的书中根本不是一个好的模式。我倾向于将常量保持在最有意义的位置或者从OO角度来看它们属于哪里，并且很少将它们组合在一个界面中。
答案 7 :(得分：0)
另一个替代方法（除了枚举之外）将是一个非可实例化的类（私有构造函数），用于在枚举不适合时收集常量（如字符串，整数等）。
另外，也许只有在使用它的地方才能看到该类。