Java 什么是常数接口最优雅的替代方案？

我一直在看一个离岸组织开发的一些代码。我看到每个定义的模块至少有一个“常量接口”。 示例（非真实世界）：

据我所知，这是一种反模式，因为它们在运行时没有任何实用性，应该以不同的方式避免或处理。

---

什么是优雅的方式来表达这一点？可以改用

enum

吗？

使用

私有
构造函数将接口转换为
最终的
类。
我更喜欢将常量放在它们最相关的类中，然后如果我必须在其他地方引用它们，就这样做-如果有意义的话，可以使用静态导入（例如，对于
数学.PI
）

在接口中放置常量的唯一真正原因是允许您“实现”方法释放接口并通过简单的名称访问常量，而无需任何进一步的限定。静态导入消除了这一原因。
使用最终的不可实例化类，即带有私有构造函数的类。
除非所有参数密切相关，否则enum可能不是一个好主意例如，我想说，它们之间的关系不够密切，不足以成为枚举

但包含这样一个常量类/接口并不一定是个坏主意。它确实具有集中化的优势，这意味着这些配置内容可以很容易地移动到程序之外，例如移动到属性文件、命令行解码器、数据库甚至套接字接口，而对程序的影响最小其他课程。这实际上是一个设计将走向何方的问题

除非你想沿着这条路走下去，否则我会说，在使用相应参数的类中，静态期末考试是一条路，正如已经建议过的那样。
Wow！down vote。但是为什么呢？我建议严格测试他们编程的功能，不要担心这样的问题，直到你发现坏掉的f函数性。在某些情况下，静态导入不能完全达到预期效果。如果.java文件中有多个类（例如嵌套文件）每个类都可以有自己的常量集，其中一些可以有重叠的名称。使用静态导入将意味着冲突。@emory:True。另一方面，无论如何，我不想在这种情况下使用接口技巧-在同一个文件中使用相同的常量名称意味着不同的东西对我来说是个坏主意。@Jon Skeet-在接口中放置常量的唯一真正原因是允许您“实现”无方法接口，并通过其简单名称访问常量-听起来很有趣。但从面向对象的角度来看，这不是一个更糟糕的做法吗？这在现实世界中有什么关系？-谢谢你的回答。@ring Bearner:哪种做法更糟糕？你的意思不是很清楚。但是，是的，创建接口只是为了保存常量是个坏主意。我同意。使用枚举和或类而不是interfaces可能会破坏现有的代码。我不认为这是一个严重的反模式。
public interface RequestConstants{
  //a mix of different constants(int,string,...)
  public static final int MAX_REQUESTS = 9999;
  public static final String SAMPLE_REQUEST = "Sample Request";
}