仅与常量接口

最近我遇到了一段代码，其中我找到了一个只有常量的接口。 并且使用静态导入在类中访问这些常量。 常数更多（约30至50）。

就个人而言，我认为这不是一个好习惯。 这就是为什么它根据Effective Java被称为Constant Interface Antipattern。 我没有找到任何有理由去进行这种编码。

此外，仅当我们的应用程序中的许多类导入的常量很少时，才应使用静态导入。

谁能告诉我是否有任何其他充分的理由去寻找常数界面？

Answer 1

当然，在引入枚举之前，如果你需要在许多类之间共享大量常量，那么Constant Interface可能是最实用的方法。

如果这些常量只用在一个类中，那么其他答案中的注释（“要避免的模式”）是非常有效的 – 如果由使用它们的类声明它们将是最有用的。

对于较新版本的Java，我将使用允许设置值的构造函数转向枚举。 但是仍然如此，如果值集仅由单个类使用，则最有意义的是在该类中声明它们而不是单独声明它们。

Answer 2

如果这些常量进行了一些逻辑分组，那么我可以使用枚举

Answer 3

我根本不喜欢这个成语。 为什么要将常量与它们使用的上下文分开？ 我觉得很困惑。

这个设计强制一个类需要一个常量来实现一个充满它们的整个接口。 所有这些常数都是公开的。

enum的想法很好。 除此之外的任何东西。

Answer 4

常见的替代方法是在实用程序类而不是接口中定义公共静态最终常量。 获取常量接口，将其重新定义为类，在每个声明上放置“public static final”，并引用由类名限定的这些变量，而不是通过实现接口。

我倾向于将一组常量与枚举区分开来。

Answer 5

这个链接有一个有效的讨论http://www.theserverside.com/discussions/thread.tss?thread_id=19221

最重要的是尽可能避免使用常量接口

Answer 6

这个解决方案并不是很好，但有时候是将所有常量聚集在一个地方的最佳选择，例如应用程序中使用的翻译键。

使用接口我们可以创建这些接口的整个存储，而不是复制它们。

Answer 7

一点也不。 我会尽可能地避免这种模式，在我的书中根本不是一个好的模式。 我倾向于将常量保持在最有意义的位置或者它们属于OO视角的位置，并且很少将它们组合在一个界面中。

Answer 8

另一个替代方法（除了枚举之外）将是一个非可实例化的类（私有构造函数），用于在枚举不适合时收集常量（如字符串，整数等）。

另外，也许只有在使用它的地方才能让包看到它。