常量接口最优雅的替代方案是什么？答案

【问题标题】：What are most graceful alternatives to constant interfaces?常量接口最优雅的替代方案是什么？
【发布时间】：2011-09-15 19:47:05
【问题描述】：

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

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";
}

根据我的理解，这是一种反模式，因为它们在运行时没有任何实用性，应该避免或以不同的方式解决。有什么优雅的方式来表示这一点？可以用enums代替吗？

【问题讨论】：

哇！否决票。但为什么呢？
我建议严格测试他们的编程功能，在发现功能损坏之前不要担心此类问题。

标签： java constants

【解决方案1】：

我更喜欢将常量放在它们最相关的类中，然后如果我必须在其他地方引用它们，就这样做 - 可能在有意义的情况下使用静态导入（例如 Math.PI）。

将常量放在接口中的唯一真正原因是允许您“实现”无方法接口并通过它们的简单名称访问常量而无需任何进一步的限定。静态导入消除了这个原因。

【讨论】：

静态导入在某些情况下并不能完全达到预期的效果。如果我在 .java 文件中有多个类（例如嵌套文件），每个类都可以有自己的一组常量，其中一些可以有重叠的名称。使用静态导入将意味着冲突。
@emory：是的。另一方面，无论如何我都不想在这种情况下使用接口技巧 - 在同一个文件中使用相同的常量名称表示不同的东西对我来说听起来是个坏主意。
@Jon Skeet - “将常量放在接口中的唯一真正原因是允许您“实现”无方法接口并通过它们的简单名称访问常量” - 听起来很有趣.但从 OO 的角度来看，这不是更糟糕的做法吗？这与现实世界有什么关系？ - 感谢您的回答。
@ring bearer：which不是更糟糕的做法吗？你的意思不是很清楚。但是，是的，创建接口只是为了保存常量是个坏主意。

【解决方案2】：

除非所有参数都密切相关，否则枚举可能不是一个好主意。对于您示例中的两个参数，我想说它们的相关性不够紧密，不足以成为枚举。

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

但是，除非您正在考虑走这条路，否则我会说在使用相应参数的类中使用静态决赛是可行的方法，正如已经建议的那样。

【讨论】：

我同意。使用枚举和/或类而不是接口可能会破坏现有代码。我不认为这是一种严重的反模式。

【解决方案3】：

使用private 构造函数将接口转换为final 类。

【讨论】：

【解决方案4】：

使用最终的不可实例化类，即具有私有构造函数的类。

【讨论】：