Java 常量类中的多个接口

使用多个接口在单个接口内声明属于不同层（如控制器、服务、DAO等）的常量是否是一种良好的做法，以便根据常量所属的层分离常量，例如如下所示：

public interface TestConstants
{
    interface UIConstants
    {
        public static String FIRST_UI_CONSTANT = "FIRST";
        public static String SECOND_UI_CONSTANT = "SECOND";
    }

    interface ServiceConstants
    {
        public static String FIRST_SVC_CONSTANT = "FIRST";
        public static String SECOND_SVC_CONSTANT = "SECOND";
    }

    interface DAOConstants
    {
        public static String FIRST_DAO_CONSTANT = "FIRST";
        public static String SECOND_DAO_CONSTANT = "SECOND";
    }
}

---

看起来很漂亮，不是吗。一种着色体系结构

然而，它也有它的缺点

常量被复制到导入类中，导入将从.class文件中消失。这意味着当接口文件被更改时，编译器可能不会重新编译导入类（编译器的一个愚蠢的缩写），而使用旧的常量值。现在，常量值不经常更改，“干净项目”很容易手动调用

然后这个接口可能经常被更改，因为它将几个方面结合在一起。这是一种糟糕的风格：太多不必要的耦合。版本控制合并越多，需要的vcs更新越频繁，重新编译越多

最后，接口使得使用常量变得很有诱惑力。常量不是面向对象的（枚举可以是OO）。有许多条件case分支是一个坏迹象。架构应该更具建模性。常数甚至不允许模块化可见性。此外，诸如int和String之类的基本类型有时最好包装在它们自己的值类中（计算、验证、规范化）

对于局部常量可以说很多，这是一种不重复的支持，最小的模块化

综上所述，拥有多个接口，就像名称空间一样，比为不同目的混合常量要好得多。不过，您应该介绍并传达一致的用法

具有冗余名称（接口名称在常量名称中重复）的示例适用于以下样式：

class C implements TestConstants.UIConstants;
    ... FIRST_UI_CONSTANT

就我个人而言，我更喜欢

class C implements TestConstants;
    ... UIConstants.FIRST

---

如上所述，枚举会更好。

我认为

接口

应该用于定义契约，而不是常量。使用枚举定义常量，如果不能使用枚举，请使用标记为

final

且具有私有构造函数的普通java类，并将所有字段/常量定义为

public static final

@VinodMadyalkar。这正是有效的Java第二版第19项“仅使用接口定义类型”中所描述的。您能详细说明为什么需要这些常量吗？你在用它们干什么？@All:抱歉刚刚更新了我的问题。。一个接口中有多个接口。相同的注释：不要为此使用接口。使用最终的、不可实例化的静态（如果嵌套）类。