关于 "java中常量定义在interface中好还是定义在class中好" 的一些思考

原文链接 http://blog.csdn.net/voo00oov/article/details/50433672

java中interface中定义变量都是"public static final" 类型的, 也就是常量, 因此很多人在interface定义常用的常量(这也是本人偏爱的方式);

由此却引起了不少风波, 网上关于此问题的讨论也非常多, 下面说说我的个人意见:

下面是功能等同的两种定义常量的方式:

package com.example;

public final class Constants {
    private Constants() {}
    public static final int A = 100;
    public static final int B = 100;
    public static final int C = 100;
    public static final int D = 100;
}

package com.example;

public interface Constants {
    int A = 100;
    int B = 100;
    int C = 100;
    int D = 100;
}

类定义常量和接口定义常量:

1. 类定义常量, 需要定义成final且定义一个private的构造方法, 这样做是为了不让其他类继承, 禁止实例化此类,

调用时直接以"类.常量"的方式调用.

2. 接口中定义的"变量", 其实就是常量, 接口中的"变量"默认都是 "public static final"类型, 即为常量,

因此接口可以省略"public static final"而直接写成 "type variable".

3. 用如上的类定义常量, 不能实例化也不能被继承, 看起了完美无缺;

4. 接口定义常量, 虽不能实例化, 确可以被其他类实现;

因此有这么一种设计模式"The constant interface pattern". 所谓的"常量接口模式", 就是其他类要使用接口中定义的常量,

就实现该接口. 我认为这是对接口的烂用. 接口中定义的常量应为所有类频繁使用的常量, 但并不是每个类都使用了接口中定义的所有常量,

因而导入了不必要的常量到这个类中, 并且导入后这个类的子类也会基础导入的常量, 这样会导致混乱, 应当避免此种用法.

5. 在interface和class中定义相同的常量, interface生成的class文件比class生成的class文件会更小, 而且更简洁, 效率更高.

总结:

1. 不要使用"常量接口模式", 此模式会导致类中的常量混乱, 增加维护难度.

2. 不要使用静态导入, import static *****

我非常不赞同这种使用常量的方法, 因为import static会导致可维护性下降, 维护的人看代码时, 不是那么清楚或者不那么迅速的知道这个常量位于哪个文件中.

建议使用常量的地方直接 "接口.常量名" 的方式使用

3. 还有人说用这种方式定义常量: public abstract class Constants {}, 很容易看出这种方式定义常量的目的: 禁止实例化.

但是"abstract class"的目的是为了让其他类继承, 因此语意别扭, 同样具有interface定义常量的确定 ----- 即可以被继承,

其实解决上述问题更优美的方式是用final修饰类并给类定义一个private构造方法.

4. 对于用是用interface定义常量还是使用class定义常量, 看个人喜好. 个人觉得interface定义常量更为优美,

1. 代码更简洁

2. 生成的class文件更小, jvm不要考虑类的附加特性, 如方法重载等, 因而更为高效.

tips: 这是一种反模式的用法, 很多人不喜欢这种用法, 如果我们知道它的优缺点, 延长避短, 也是无可厚非的,

还有一点是不要把这种用法用成"常量接口模式", 个人觉得"常量接口模式"确实是一种对interface的"pool use".