Chapter 6 Enums and Annotations
Item 30: Use enums instead of int constants
Enum类型无非也是个普通的class，所以你可以给他加class能有的东西，比如constructor：
public enum Planet {
MERCURY(3.302e+23, 2.439e6),
VENUS (4.869e+24, 6.052e6),
EARTH (5.975e+24, 6.378e6)；
private final double mass; // In kilograms
private final double radius; // In meters
// Constructor，不能是public的哦（我猜的）
Planet(double mass, double radius) {
this.mass = mass;
this.radius = radius;
}
我记得我在thinking in java里看过，比如这里的EARTH无非就是编译器自动生成的Plannet类型的一个field：static final Plannet EARTH = Planet(5.975e+24, 6.378e6)。
那么如果你想加一些constant specific（不同的enum实例有不同的行为）的行为的话，可能你会用这么做：
public enum Operation {
PLUS, MINUS, TIMES, DIVIDE;
double apply(double x, double y) {
switch(this) {
case PLUS: return x + y;
case MINUS: return x - y;
case TIMES: return x * y;
case DIVIDE: return x / y;
}
throw new AssertionError("Unknown op: " + this);
}
}
这里我学到一招，如果不写那句throw，编译会不通过“你必须在每个代码可能到达的地方写一个return”。但是，我个人感觉，switch case是一切不良编程习惯的典型代表，如果你要加一个新的enum constant，你还要加一个case，很可能你就忘了然后就吃瘪了。于是你可以用下面这种语法：
// Enum type with constant-specific method implementations
public enum Operation {
PLUS { double apply(double x, double y){return x + y;} },
MINUS { double apply(double x, double y){return x - y;} },
TIMES { double apply(double x, double y){return x * y;} },
DIVIDE { double apply(double x, double y){return x / y;} };
abstract double apply(double x, double y);
}
应该很好懂所以我不解释了。
每一个Enum类型都有一个valueOf(String)，从一个constant的名字得到一个真正的这个constant，但是如果你override了toString方法，也就意味着你的constant的名字和toString不一致，所以最好写一个fromString(String)方法，方法参考书上。
但是上面这种解决constant specific的方法有个缺点就是，不能“share code”，比如
// Enum that switches on its value to share code - questionable
enum PayrollDay {
MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY,SATURDAY, SUNDAY;
private static final int HOURS_PER_SHIFT = 8;
double pay(double hoursWorked, double payRate) {
double basePay = hoursWorked * payRate;
double overtimePay; // Calculate overtime pay
switch(this) {
case SATURDAY: case SUNDAY:
overtimePay = hoursWorked * payRate * 2;//假如周末是两倍加班费
default: // Weekdays
overtimePay = hoursWorked <= HOURS_PER_SHIFT ?0 : (hoursWorked - HOURS_PER_SHIFT) * payRate * 1.5 ;//假如平时是1.5倍
break;
}
return basePay + overtimePay;
}
}
这里的pay方法就是根据输入的某一天的工作小时数和payrate（就是你每小时的基本工资）计算出这一天的总薪酬（基本工资+加班费），比如计算星期一的薪酬：MONDAY.pay(10, 50)。
刚才说过了，switch case这种写法没有很好的可维护性，刚才介绍的“constant-specific method”语法也一样，你只能通过增加一些helper method来减少重复代码，不管怎么样都会降低可读性。
其实你可以想一下这个问题的本质：对于每个上面enum constant，你都需要一个计算overtime pay的strategy，所以你可以把这件事委托给另一个人专门负责（Strategy Pattern）：
enum PayrollDay {
MONDAY(PayType.WEEKDAY), TUESDAY(PayType.WEEKDAY),
WEDNESDAY(PayType.WEEKDAY), THURSDAY(PayType.WEEKDAY),
FRIDAY(PayType.WEEKDAY), SATURDAY(PayType.WEEKEND),
SUNDAY(PayType.WEEKEND);
private final PayType payType;
PayrollDay(PayType payType) {
this.payType = payType;
}
double pay(double hoursWorked, double payRate) {
return payType.pay(hoursWorked, payRate);//委托给payType去做
}
// The strategy enum type
private enum PayType {
WEEKDAY {
double overtimePay(double hours, double payRate) {
return hours <= HOURS_PER_SHIFT ? 0 : (hours - HOURS_PER_SHIFT)
* payRate * 1.5;
}
},
WEEKEND {
double overtimePay(double hours, double payRate) {
return hours * payRate * 2;
}
};
private static final int HOURS_PER_SHIFT = 8;
abstract double overtimePay(double hrs, double payRate);
double pay(double hoursWorked, double payRate) {
double basePay = hoursWorked * payRate;
return basePay + overtimePay(hoursWorked, payRate);
}
}
}
虽然这个方法乍一看很繁琐，但是如果你的enum constants一旦变多就会体现出优势（所有strategy pattern的优势）。这个pattern适用于这种情况：if multiple enum constants share common behaviors。
虽然switch不适用于enum的内部实现，但是对某个enum的client来说还是很适用的。
Item 31: Use instance fields instead of ordinals
每一个enum constant都关联着一个int，而你可以用ordinal()来获得这个int。这条item的意思就是，永远都不要依靠ordinal()来计算或得到某个状态值，甚至最好完全不要用ordinal()，因为这个方法主要是被设计成服务于EnumSet和EnumMap的，举例：假设你要给每一个enum constant编个号，千万别这样：
// Abuse of ordinal to derive an associated value - DON'T DO THIS
public enum Student {
JACK,JOE,JANE,JAKE;
public int studentNumber() { return ordinal() + 1; }
}
坏处一大堆，比如如果你声明enum constants的顺序变了，那么各个学生的编号就变了。正确做法是：
public enum Student {
JACK(1),JOE(2),JANE(3),JAKE(4);
private final int studentNumber;
Student(int number) { this.studentNumber= number; }
public int studentNumber() { return studentNumber; }
}
Item 32: Use EnumSet instead of bit fields
以前看Win32编程的时候经常看到这种：
// Bit field enumeration constants - OBSOLETE!
public class Text {
public static final int STYLE_BOLD = 1 << 0; // 1
public static final int STYLE_ITALIC = 1 << 1; // 2
public static final int STYLE_UNDERLINE = 1 << 2; // 4
public static final int STYLE_STRIKETHROUGH = 1 << 3; // 8
// Parameter is bitwise OR of zero or more STYLE_ constants
public void applyStyles(int styles) { ... }
}
然后你可以这么用：text.applyStyles(STYLE_BOLD | STYLE_ITALIC);
现在有更好的选择：EnumSet，它实现了Set接口，于是可以把上面的改进一下：
// EnumSet - a modern replacement for bit fields
public class Text {
public enum Style { BOLD, ITALIC, UNDERLINE, STRIKETHROUGH }
// Any Set could be passed in, but EnumSet is clearly best
public void applyStyles(Set<Style> styles) { ... }
}
然后可以这么用：text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC));
唯一的缺点是1.6版本的EnumSet不是immutable的。
Item 33: Use EnumMap instead of ordinal indexing
EnumMap是“key是Enum类型的Map”，比HashMap更高效，其内部用数组实现。
当你需要把一种enum constant映射到另一个value的时候，不要用”用ordinal方法作为数组下标“的数组 的方法，可读性和可维护性都很差。举个具体的例子吧（复习时可以选择性地跳过），首先千万别这样：
//植物类，分为“一年绿一次”，“常年绿”，“半年绿一次”三种类型。
public class Herb {
public enum Type { ANNUAL, PERENNIAL, BIENNIAL }
private final String name;
private final Type type;
Herb(String name, Type type) {
this.name = name;
this.type = type;
}
@Override public String toString() {return name;}
}
然后现在我们现在有a list of herbs，然后要根据类型分类，把相同类型的herb放到一个Set里去，所以有三种类型就有三个Sets，我们用一个Set[]数组herbsByType来表示：
// Using ordinal() to index an array - DON'T DO THIS!
Herb[] garden = ... ;
// Indexed by Herb.Type.ordinal()
Set<Herb>[] herbsByType = (Set<Herb>[]) new Set[Herb.Type.values().length];
for (int i = 0; i < herbsByType.length; i++)
herbsByType[i] = new HashSet<Herb>();
for (Herb h : garden)
herbsByType[h.type.ordinal()].add(h);
// Print the results，也就是怎么取回来
for (int i = 0; i < herbsByType.length; i++) {
System.out.printf("%s: %s%n",Herb.Type.values()[i], herbsByType[i]);
}
这种做法问题一大堆，随便举一个：因为数组和泛型不兼容，所以你必须有一个有警告的cast：(Set<Herb>[])（这里我暂停想了一下为什么不能创建一个Set<Herb>的数组，个人觉得是因为数组是runtime保证type safe的，到了runtime的时候Set<随便什么>都等于Set，数组分不清）。正确做法是：
// Using an EnumMap to associate data with an enum
Map<Herb.Type, Set<Herb>> herbsByType =
new EnumMap<Herb.Type, Set<Herb>>(Herb.Type.class);
for (Herb.Type t : Herb.Type.values())
herbsByType.put(t, new HashSet<Herb>());
for (Herb h : garden)
herbsByType.get(h.type).add(h);
System.out.println(herbsByType);
上面传给EnumMap的constructor的参数是一个Type Token：Herb.Type.class。
有的时候你可能需要两个enum作为key，就相像你需要一个二维平面的坐标(x,y)来得到一个位置。书上举得例子是：从liquid到solid是freezing，从liquid到gas是boiling等等，也就是：从两个“物质形态enum“（固态液态气态）map到一种”变化enum“（freezing，boiling...）。（艹，我顺便去复习了一下初中物理，原来从固态到气态叫升华（SUBLIME）） 下面举一下反例：
// Using ordinal() to index array of arrays - DON'T DO THIS!
public enum Phase { SOLID, LIQUID, GAS;
public enum Transition {
MELT, FREEZE, BOIL, CONDENSE, SUBLIME, DEPOSIT;
// Rows indexed by src-ordinal, cols by dst-ordinal
private static final Transition[][] TRANSITIONS = {
{ null, MELT, SUBLIME },
{ FREEZE, null, BOIL },
{ DEPOSIT, CONDENSE, null }
};
// Returns the phase transition from one phase to another
public static Transition from(Phase src, Phase dst) {
return TRANSITIONS[src.ordinal()][dst.ordinal()];
}
}
}
这个二维数组想象成一张表格就行。那么用EnumMap怎么做？这里我觉得需要一种“技巧”，因为EnumMap的key没法定义成“（x，y）”这种形式，所以你可以这样声明它的类型：Map<Phase, Map<Phase,Transition>> m，可以这么理解：第一次指定一个Phase的时候：m.get(src)得到的是“那张表格的某一行”，然后接着第二次get的时候：m.get(src).get(dst)得到的就是刚才那一行的某一列了。我个人认为，这种“技巧”是为了得到EnumMap的性能，如果不需要考虑性能，完全可以用"(x,y)"作为一个HashMap的key，感觉会比这个“技巧”好理解，从而提升可读性。下面放一下具体的代码：
public enum Phase {
SOLID, LIQUID, GAS;
public enum Transition {
MELT(SOLID, LIQUID), FREEZE(LIQUID, SOLID), BOIL(LIQUID, GAS), CONDENSE(
GAS, LIQUID), SUBLIME(SOLID, GAS), DEPOSIT(GAS, SOLID);
private final Phase src;
private final Phase dst;
Transition(Phase src, Phase dst) {
this.src = src;
this.dst = dst;
}
// Initialize the phase transition map
private static final Map<Phase, Map<Phase, Transition>> m = new EnumMap<Phase,
Map<Phase, Transition>>(Phase.class);//传入作为key的Enum类型
static {
for (Phase p : Phase.values())
m.put(p, new EnumMap<Phase, Transition>(Phase.class));
for (Transition trans : Transition.values())
m.get(trans.src).put(trans.dst, trans);//这句加粗
}
public static Transition from(Phase src, Phase dst) {
return m.get(src).get(dst);
}
}
}
你可以注意到这里把Transition这个Enum Type扩展了一下，为的是上面那句加粗的语句，同时也提供了“(x,y)到z的映射”，这样就不用再被“下标是几的元素对应的是谁”的问题搞脑子了，此外，如果你要新加一种enum constant的话，这种写法甚至不需要你修改任何“EnumMap的部分”，很爽。
Item 34: Emulate extensible enums with interfaces
因为Enum类型不能被继承，如果你想“模拟继承”，可以给你的Enum加个接口。而你的Enum的所有API都是通过这个接口暴露出来的，也就是client在用你的Enum的时候，变量类型肯定是这个接口。这样的话client就可以实现自己的Enum类型，只要实现这个接口就行，然后任何需要“base enum”的地方，你都可以用你的“extension enum”来代替。个人理解：这里说继承不如说是“扩展”，只是如果库的enum类型无法满足你的需求，你就可以实现自己的，但是你自己的并没有包含原先enum类型中的任何功能。
作为类库实现者，你可以定义如下的方法，让其参数可以接收client自定义的enum：
public static <T extends Enum<T> & Operation> void test(Class<T> opSet)
<T extends Enum<T> & Operation>的意思是T必须满足 是一个Enum类型并且实现了Operation这个接口。然后比如client实现了一个叫ExtendedOperation的enum类型，直接传ExtendedOperation.class进去就行了。
或者你也可以把方法定义成：
public static void test(Collection<? extends Operation> opSet)
这样的好处是client可以自己先combine一些opSet（来自“base enum”的也好，来自其“extension enum”的也好）到同一个集合，然后再传进去，比如用Arrays.asList(ExtendedOperation.values())
但缺点是在方法内无法用EnumSet和EnumMap。
Item 35: Prefer annotations to naming patterns
这里的naming patterns就是指在Annotation出现之前，只能用某种约定的命名格式来完成 现在用annotation可以强制 的事。比如JUnit起初要求测试方法名必须以test开头，这种做法的坏处一大堆。而用annotation就好很多，下面举几个Annotation定义和用法的具体例子（复习时可以选择性跳过）：
/**
* Indicates that the annotated method is a test method.
* Use only on parameterless static methods.
*/
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Test {
}
上面那段注释是因为我们在tool或framework中用 被这个Annotation mark过的方法 的时候，假定都是static和parameterless的方法， 往下看你就懂了。用这个Annotation很简单，在方法声明上面一贴就行，而这么一贴对方法本身或者其所在的类没什么影响，只是一个信息（提供给那些对这个信息感兴趣的tools或者framework），比如像这样：
public class RunTests {
public static void main(String[] args) throws Exception {
int tests = 0;
int passed = 0;
Class testClass = Class.forName(args[0]);
for (Method m : testClass.getDeclaredMethods()) {
if (m.isAnnotationPresent(Test.class)) {
tests++;
try {
m.invoke(null);
passed++;
} catch (InvocationTargetException wrappedExc) {
Throwable exc = wrappedExc.getCause();
System.out.println(m + " failed: " + exc);
} catch (Exception exc) {
System.out.println("INVALID @Test: " + m);
}
}
}
System.out.printf("Passed: %d, Failed: %d%n", passed, tests - passed);
}
}
因为上面用了m.invoke(null)，所以如果没有遵守“必须在static和parameterless的方法上mark这个Annotation“的规定，就会抛出InvocationTargetException。
现在我们再写一个Annotation，用来标记那些“期待指定异常”的方法：
// Annotation type with a parameter
/**
* Indicates that the annotated method is a test method that
* must throw the designated exception to succeed.
*/
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ExceptionTest {
Class<? extends Exception> value();
}
我发现定义Annotation的时候不需要指定构造函数，只需要指定它的fields就行了。下面是这个Annotation的用法：
@ExceptionTest(ArithmeticException.class)
public static void m1() { // Test should pass
int i = 0;
i = i / i;
}
下面是相应的“Test Runner”的代码：
public class RunTests {
public static void main(String[] args) throws Exception {
int tests = 0;
int passed = 0;
Class testClass = Class.forName(args[0]);
for (Method m : testClass.getDeclaredMethods()) {
if (m.isAnnotationPresent(ExceptionTest.class)) {
tests++;
try {
m.invoke(null);
System.out.printf("Test %s failed: no exception%n", m);
} catch (InvocationTargetException wrappedExc) {
Throwable exc = wrappedExc.getCause();
Class<? extends Exception> excType =
m.getAnnotation(ExceptionTest.class).value();
if (excType.isInstance(exc)) {
passed++;
} else {
System.out.printf("Test %s failed: expected %s, got %s%n",
m, excType.getName(), exc);
}
}
}
}
System.out.printf("Passed: %d, Failed: %d%n", passed, tests - passed);
}
}
这段代码从我们定义的ExceptionTest中提取出了value字段，然后判断和真正抛出的异常是不是一致。
再要加强的话，你还可以修改ExceptionTest让它接受一系列异常的class object，表示抛出其中任何一个异常都视为test通过，那么你只要把value这个字段改一下就行：
Class<? extends Exception>[] value();//只是变成数组而已
然后在用这个Annotation的时候，刚才上面所有的“single parameter”语法也是可以的，表示一个“single-element array”。而“multi-element”的参数语法如下：
@ExceptionTest({ IndexOutOfBoundsException.class, NullPointerException.class })
public static void someMethod(){...}
对应的test runner也很好改，这里就不写了。
所以说，其实除了tool或者某些framework的实现者，我们一般是不需要定义Annotation的，但是我们应该用 tool或者framework以及Java platform本身提供的Annotation。
Item 36: Consistently use the Override annotation
像我就曾经因为C#带过来的命名习惯，把toString写成ToString结果也没加@Override，结果就变成overload了。所以应该养成用@Override的习惯，但是override接口或抽象类中的方法时，可以不加@Override
Item 37: Use marker interfaces to define types
一个marker interface就是一个里面啥方法声明都没有的interface。一个类实现这么一个interface只是为了“标记”一下自己有某种特点，比如Serializable这个interface。与这个marker interface类似的就是“marker annotation”，比如上上个item中最一开始的那个Test就是。作者认为marker interface和marker annotation各有各的好和坏。看到这我不经想问“你TM不是在讲clone方法的时候说用interface来标记某种特点是不对的吗？”，然后我貌似理解他的意思了：作者的意思是：Object里面的clone方法不应该接受一个Object类型的参数然后再if（obj instanceof Cloneable），而应该直接让Object里面的clone方法接受一个Cloneable类型的参数，这样就直接在编译时保证类型安全而不至于到运行时出错。marker annotation的优点在于可以“不断进化和改进”，而且可以贴在方法上；而marker interface一旦定义后就定死了，以后就不能再往里面新增方法了（Item 18）。