c/c++语言开发共享详细聊聊JDK中的反模式接口常量

前言

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

• 在接口中定义常量，比如 jdk 1.1 中的 java.io.objectstreamconstans 接口；

• 在类中定义常量，比如 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类实现了常量接口，它的所有子类的命名空间也会被接口中的常量所“污染”。

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

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

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

• 接口暗含的意思是：它是需被实现的，代表着一种类型，它的公有成员是要被暴露的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又是什么鬼？是不是还要有4、5、6、7？那这种常量定义就失去价值了。对于这种可以归类的常量，最好的常量定义方法应该就是枚举了：

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的构造方法，如果常量可以进行归类，最好使用枚举定义：枚举 > 类 > 接口。

到此这篇关于jdk中反模式接口常量的文章就介绍到这了,更多相关jdk反模式接口常量内容请搜索<计算机技术网(www.ctvol.com)!!>以前的文章或继续浏览下面的相关文章希望大家以后多多支持<计算机技术网(www.ctvol.com)!!>！

需要了解更多c/c++开发分享详细聊聊JDK中的反模式接口常量，都可以关注C/C++技术分享栏目—计算机技术网(www.ctvol.com)!