接口定义常量是坏味道，因其违背接口行为契约本质，导致语义混乱、误用风险高、编译依赖泛滥及继承污染；应改用final工具类、枚举或配置类替代。
Java 中用接口定义常量（比如 public interface Constants { String SUCCESS = "success"; int TIMEOUT = 3000; }）是一种早已过时且被明确视为“坏味道”的做法。它混淆了接口的设计本意——描述行为契约，而非存储数据。这种写法会导致语义混乱、误用风险高、编译依赖泛滥，还可能引发子类意外继承大量无关常量的问题。
为什么接口当常量池是坏味道
• 违背接口本质：接口应声明抽象方法，表达“能做什么”；而常量是静态数据，属于状态范畴，和契约无关。
• 强制实现类继承无意义成员：只要类 implements 该接口，就会自动获得所有常量字段，哪怕完全用不到，还可能造成命名冲突（如多个常量接口含同名字段）。
• 破坏封装与可维护性：常量修改需重新编译所有实现类；无法控制访问权限（接口中字段默认 public static final，无法设为 package-private 或 protected）。
• 阻碍演进：后续想把常量升级为带逻辑的配置项（如从字符串变为枚举或配置加载），接口无法承载行为，重构成本陡增。
用工具类替代接口常量
将常量统一移到 final 类 + 私有构造器 中，是最直接、兼容性强的重构方式：
• 创建一个不可实例化的工具类，例如 AppConstants：
public final class AppConstants {
private AppConstants() {} // 禁止实例化
public static final String SUCCESS = "success";
public static final int DEFAULT_TIMEOUT_MS = 3000;
public static final String CONFIG_KEY_DB_URL = "db.url";
}
• 所有使用方通过 AppConstants.SUCCESS 显式引用，语义清晰，无隐式继承副作用。
• 后续可轻松扩展：添加静态方法做校验、转换，或配合 Properties 动态加载。
按语义分组，用枚举或专用配置类管理
当常量具备明确业务含义或存在状态关系时，优先考虑更富表现力的结构：
• 状态码/结果标识 → 用枚举：
public enum ResultStatus {
SUCCESS("success", 200),
FAILED("failed", 400);
private final String code;
private final int httpCode;
ResultStatus(String code, int httpCode) { this.code = code; this.httpCode = httpCode; }
public String getCode() { return code; }
}
• 系统级配置项（如超时、重试次数）→ 提取为 @ConfigurationProperties 类（Spring Boot）或独立的 Config 类，支持外部化配置。
• 消息模板、SQL 片段等字符串常量 → 单独建 MessageTemplates 或 SqlStatements 类，按用途聚类，避免混杂。
借助现代工具辅助识别与清理
• 使用 SonarQube 或 SpotBugs 扫描，规则 java:S1214（Constant interfaces should not be used）可自动标记接口常量用法。
• 在 IDE（IntelliJ IDEA）中启用检查：“Interface with only constants”，一键定位并建议替换。
• 替换后，全局搜索原接口名，确认所有 implements Constants 已改为显式引用，杜绝残留。
• 补充单元测试验证常量值未变，尤其注意字符串比较、数值精度等易出错点。
