写点什么

JDK 中居然也有反模式接口常量

用户头像
看山
关注
发布于: 2020 年 08 月 16 日
JDK中居然也有反模式接口常量

在实际开发过程中,经常会需要定义一个文件,用于存储一些常量,这些常量设计为静态公共常量(使用 public static final 修饰)。这个时候就出现两种选择:



  1. 在接口中定义常量,比如 JDK 1.1 中的 java.io.ObjectStreamConstans 接口;

  2. 在类中定义常量,比如 JDK 1.7 中的 java.nio.charset.StandardCharsets



这两种方式都能够达到要求:存储常量、无需实例化。下面分情况讨论下两种方式孰优孰劣。

常量接口



首先从代码的角度分析,接口中定义的变量都必须是常量,即默认使用 public static final 修饰。也就是说,在写代码的时候直接写成下面这样:



public interface ObjectStreamConstants {
short STREAM_MAGIC = (short)0xaced;
short STREAM_VERSION = 5;
}



但是在类中就必须乖乖的写成下面这种样子:



public final class ObjectStreamConstants {
public static final short STREAM_MAGIC = (short)0xaced;
public static final short STREAM_VERSION = 5;
}



从直观的感受,接口写起来方便多了。

第二个问题:因为类中写的字符比接口多,所以编译之后文件大小也是类文件比接口文件大。

第三个问题:在JVM加载过程中,接口没有类提供的额外特种(如重载、方法的动态绑定等),所以接口加载比类快。

分析到此,似乎没有什么理由不用接口定义常量了。但是,BUT,这种做法却是一种严重的反模式行为。

引用《Effective Java》中的一段描述:



The constant interface pattern is a poor use of interfaces. That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the class's exported API. It is of no consequence to the users of a class that the class implements a constant interface. In fact, it may even confuse them. Worse, it represents a commitment: if in a future release the class is modified so that it no longer needs to use the constants, it still must implement the interface to ensure binary compatibility. If a nonfinal class implements a constant interface, all of its subclasses will have their namespaces polluted by the constants in the interface.



翻译出来就是:



常量接口模式是对接口的不良使用。类在内部使用某些常量,这纯粹是实现细节。实现常量接口会导致把这样的实现细节泄露到该类的导出API中。类实现常量接口,这对于类的用户来讲并没有什么价值。实际上,这样做反而会使他们更加糊涂。更糟糕的是,它代表了一种承诺:如果在将来的发行版本中,这个类被修改了,它不再需要使用这些常量了,它依然必须实现这个接口,以确保兼容性。如果非final类实现了常量接口,它的所有子类的命名空间也会被接口中的常量所“污染”。



这样说来就很明白透彻了:



  1. 接口是不能阻止被实现或继承的,也就是说子接口或实现中是能够覆盖掉常量的定义,这样通过父、子接口(或实现) 去引用常量是可能不一致的;

  2. 同样的,由于被实现或继承,造成在继承树中可以用大量的接口、类或实例去引用同一个常量,从而造成接口中定义的常量污染了命名空间;

  3. 接口暗含的意思是:它是需被实现的,代表着一种类型,它的公有成员是要被暴露的API,但是在接口中定义的常量还算不上API。



综上所述:使用接口定义常量,是一种不可取的行为。JDK中定义的接口常量(例如java.io.ObjectStreamConstans)应该算是反面教材。



类接口



既然使用接口第一常量不可取,那就只能通过类定义常量了。虽然在JAVA中类不能够多继承,但是子类也能够“污染”父类定义常量的命名空间。所以为了常量不可变,需要将常量类定义为final的,然后再彻底点就是再定义个private的构造函数。就像java.nio.charset.StandardCharsets一样:



public final class StandardCharsets {
private StandardCharsets() {
throw new AssertionError("No java.nio.charset.StandardCharsets instances for you!");
}
public static final Charset US_ASCII = Charset.forName("US-ASCII");
public static final Charset ISO_8859_1 = Charset.forName("ISO-8859-1");
public static final Charset UTF_8 = Charset.forName("UTF-8");
}



java.nio.charset.StandardCharsets中,为了阻止各种形式的实例化,甚至在构造函数中抛出错误,也是做个够彻底的了。



枚举类型



但是,BUT,还有一种情况,比如常量中定义性别:男、女,使用上面的类常量,需要写成:



public final class Gender {
private Gender() {
throw new AssertionError("No x.y.z.Gender instances for you!");
}
public static final int MALE = 1;
public static final int FEMALE = 0;
}



因为定义的性别类型实际是int,如果手贱写成m.setGender(3)也是没有错误的,那3又是什么鬼?是不是还要有4567? 那这种常量定义就失去价值了。对于这种可以归类的常量,最好的常量定义方法应该就是枚举了:



public enum Gender {
MALE,
FEMALE
}



根据编辑的字节码,Gender实际是:



public final class Gender extends java.lang.Enum {
public static final Gender MALE;
public static final Gender FEMALE;
}



这样对于接受 Gender 类型参数的方法就只能传入 MALE 或 FEMALE 了,不再有其他选项,这就是枚举的意义。在后来的JDK中,也出现了像java.nio.file.StandardOpenOption等的枚举定义。而且枚举的定义也不只局限于这种,还有很多其他复杂定义,可以适用各种情况,以后再慢慢讨论。



结束语



定义常量不要使用接口常量,要在类中定义,最好是final类,并且定义private的构造方法,如果常量可以进行归类,最好使用枚举定义:枚举 > 类 > 接口。



其实从这段代码也能看出,一个匠人也是从菜鸟成长起来的。





发布于: 2020 年 08 月 16 日阅读数: 609
用户头像

看山

关注

公众号:看山的小屋 2017.10.26 加入

主业:程序猿,兼职:架构师。游于码界,戏享人生。

评论 (2 条评论)

发布
用户头像
同意作者的观点,惯用的约定可以避免犯错。但是接口常量类由于简单也有存在的价值,从命名上基本也避免了会有实现类,谁又会为一个常量接口添加实现呢?
2020 年 08 月 17 日 09:45
回复
赞同,从约定上可以规避很多问题,在开发中也是常用约定大于一切的方式。但是有时候会涉及多个团队协作,或者开源代码,约定的约束力就降低了。
2020 年 08 月 23 日 20:16
回复
没有更多了
JDK中居然也有反模式接口常量