要先说明一下:本书写作于2001年,正值作者参与建设JDK1.4的时期。后来到了JDK1.5,Java又将抛弃了多年的enum枚举重拾了起来。所以本条是在没有enum的时候写的。
JDK1.4及以前版本省略了enum。其实enum也是一种struct,我们当然是用class来代替之,但为什么又要单独作为一条来讲呢?是因为用类来替代枚举的时候,比较容易(或者说事实中绝大多数人都已经)犯一些错误。
比如我们要一个有三种颜色的Color,有人会定义为
public class Color {
public static final String RED = "RED";
public static final String GREEN = "GREEN";
public static final String BLUE = "BLUE";
}
这是我们非常常见的常量定义方法,通过 Color.RED 来使用。但是,你有没有想过,如果一个“不太合格”的程序员很有可能会写出这样的代码:
if (dotA.color.equals("RED")) {
......
}
这就将硬编码写到了程序中,而且如果不做Source Review是很难发现的。
这种写法还有一个“变种”,用int而非String:
public class Color {
public static final int RED = 0;
public static final int GREEN = 1;
public static final int BLUE = 2;
}
当然,那个人可以继续写出 if (dotA.color == 0) { 这样的语句,Source Review 发现的概率更低了。
但是使用int型一个小“变种”,回来带一些好处:
public class Color {
public static final int RED = 1;
public static final int GREEN = 2;
public static final int BLUE = 4;
}
每个值都是用2的整数幂,这样可以在需要保存多于一个状态的和的时候,将所有项目相加(或者位或)得到“保存值”。使用的时候,在通过此值与相应项目的位与后的Boolean值来判断是否包含之:
// 保存时
int value = Color.RED | Color.BLUE; // 或 Color.RED + Color.BLUE
saveValue(value); // 保存,可能是写入数据库
// 使用时
int value = getValue(); // 从数据库中取出
if (value & Color.RED) {
system.out.println("包含红色");
} else if (value & Color.GREEN) {
system.out.println("包含绿色");
} else if (value & Color.BLUE) {
system.out.println("包含蓝色");
}
// 结果会是:
// 包含红色
// 包含蓝色
当项目中这样的常量组越来越多,constants包中类会越来越多,甚至都想 import xxxx.constants.*; 了。于是有人开始把这些所有的常量组,放入一个Constants类中
public class Constants{
// 颜色
public static final int COLOR_RED = 1;
public static final int COLOR_GREEN = 2;
public static final int COLOR_BLUE = 4;
// 形状
public static final int SHAPE_CIRCLE = 1;
public static final int SHAPE_RECTANGLE = 2;
public static final int SHAPE_TRIANGLE = 4;
......
}
现在import一个类就好了,但是,那个人又来了,这次他吸取了之前的教训,没有硬编码了,但是他写了:
if (dotA.color == Constants.SHAPE_CIRCLE) { // A点的颜色是圆形吗? &^!#&^*`~ 倒!
.......
这样的语句是不会被编译器挑出来的,那么你能做的,除了祈祷就是痛哭了!在之前的模式下,没有写成 if (dotA.color == Shape.CIRCLE) 就已经不错了。
面对这个问题,书中给出了一个“尚未被人知晓”的方法——类型安全枚举模式。注意,它只是一种模式,再次强调JDK1.5之前并没有枚举,它实质上还是一个类。
public class Color {
private final String name;
private Color(String name){ // 使用者无法创建这个类的实例
this.name = name;
}
public String toString() {
return this.name;
}
public static final Color RED = new Color("red");
public static final Color GREEN = new Color("green");
public static final Color BLUE = new Color("blue");
}
私有的构造函数,保证了使用者无法创建这个类的实例,除了通过公有的静态final域导出的Color对象外,永远也不会再有其他实例存在。
所谓“类型安全”正式它提供了编译时的类型安全性。任何传入的非null的对象引用,一定表示了三种颜色中的一种。这样的模式下,即防止了类型错误,有防止了硬编码问题。
if (dotA.color.equals(Color.RED)) { // 前提:dotA的实现类中,color的类型既不是int也不是String,而是Color
......
}
我们看到了两大好处。再看看JDK1.5提供的enum关键字(它对应一个类Enum),从使用方法和特征来说,类型安全枚举模式和JDK1.5的enum枚举是非常相似的。那么在没有枚举的年代,作者尚且建议我们使用类型安全枚举模式,如今有了enum,我们就更没有理由拒绝它了。
但是,类型安全枚举模式和enum枚举就没有弱点吗?当然不是,首当其冲的就是刚才提到的,当常量组非常多的时候,使用N多的类型安全枚举模式或enum枚举,可能是一件让人头痛的事情。也许你会因为这一点而一票否决了它。
再有就是如果对应枚举中项目的值(如前例中的dotA.color)将要保存到数据库或外部文件时,势必要用一个int或String来代表之,为此可能要在类型安全枚举类中增加一个private value,然后toString方法返回这个value的String形式;或者在enum中定义抽象方法(类似toString)。但这也可能导致toString方法的滥用,而失去“类型安全”的保护。
最后,当类型安全枚举模式的类(没有研究enum枚举可否)实现了序列化后,如果期待不同版本程序序列化出来的字符流可以相互反序列化,那么后续版本就只能够在原来的最后面追加元素。(当然这一点对于int型和String型常量类也是一样的,而且还可能更糟)
本来还想好好研究一下enum,但是,刚刚得知稍后要进行的公司羽毛球比赛被抽到的下下签,没有心情了,以后再说吧。今天的笔记就写到这儿了。
【Effective Java 学习笔记】系列连载专题请见:
http://tonylian.iteye.com/categories/64208