討論列舉和註解的最佳實踐。

30. 用enum代替int常量

列舉型別(enum type)是指由一組固定的常量組成合法值得型別，在程式語言還沒有引入列舉之前，表示列舉型別的常用模式是宣告一組具名的int常量，稱作int列舉模式。

• int列舉模式的不足

  1. 它在型別安全性和使用方便性方法沒有任何幫助
  2. 採用int列舉模式的程式是十分脆弱的。因為int列舉是編譯時常量，被編譯到使用它們的客戶端中，如果int值發生變化，則客戶端就必須重新編譯。如果不編譯，則它們的行為就是不確定的。
  3. 打印出int列舉常量的字串，並沒有很便利的方法。要便利一個組中所有的int列舉常量、獲取int列舉組大小等這些都沒有很可靠的方法。

• String列舉模式
  int列舉模式的變體，同樣也有很大的不足。雖然它提供了可列印的字串，但是它會導致效能問題，因為它依賴於字串的比較操作；

• 列舉enum，Java的列舉本質上是int
  它們就是通過公有的靜態final域為每個列舉常量匯出例項的類，因為沒有可訪問的構造器，列舉型別是真正的final；不能例項化，只能訪問已宣告過的列舉常量。
  即列舉型別是例項受控的，它們是單例的泛型化，本質上式單元素的列舉。

  • 包含同名常量的多個列舉型別可以在同一個系統中和平共處，因為每個型別都有自己的名稱空間(在不同的類下)。
  • 可以增加或重排列舉型別中的常量，而無需重新編譯它的客戶端程式碼，因為匯出的常量域在列舉型別和它的客戶端之間提供了一個隔離層：常量值並沒有被編譯到客戶端程式碼中，而是在int列舉模式之中。
  • 可以呼叫toString()方法將列舉轉換成可列印的字串。
  • 可以新增任意的方法和域，並可以實現任意的介面。
  • 可以遍歷

• 與列舉常量關聯的有些行為，可能只需要用在定義了列舉的類或者包中。這種行為最好被實現成私有的或者包級私有的方法。

• 如果一個列舉具有普遍適用性，就應該成為一個頂層類；如果它只是用在一個特定的頂層類中，它應該被作為該頂層類的一個成員類。
  例如：java.math.RoundingMode列舉類。

• 有時候需要在不同的列舉型別上表現本質不同的行為，採用如下這種方法：在列舉型別中宣告一個抽象方法，並在特定常量的類主體(constant-specific class body)中實現該抽象方法。
  這種方法被稱作特定於常量的方法實現(constant-specific method implementation)

  。

public enum Operation {
    PLUS {
        @Override double apply(double x, double y) {
            return x + y;
        }
    },
    MINUS {
        @Override double apply(double x, double y) {
            return x - y;
        }
    },
    TIMES {
        @Override double apply(double x, double y) {
            return x * y;
        }
    },
    DIVIDE {
        @Override double apply(double x, double y) {
            return x / y;
        }
    };

    abstract double apply(double x, double y);
}

• 特定於常量的方法實現有一個美中不足的地方，它們使得在列舉常量中共享程式碼變得困難。
  可以增加抽象方法、呼叫不同的輔助方法，但這樣會產生大量的樣板程式碼，降低可讀性。
  可以使用策略列舉(strategy enum)，即巢狀一個私有列舉，把大量計算放在其中，外部將呼叫該巢狀列舉常量來委託計算。雖然這種模式沒有switch語句那麼簡潔，但更加安全、靈活。

• 列舉的效能缺點：
  裝載和初始化列舉時會有空間和時間的成本。

總之，與int常量相比，列舉型別有很大優勢，要易讀、更安全、功能更強大。善用列舉，另外如果多個列舉常量同時共享相同的行為時，考慮使用策略列舉。

31. 用例項域代替序數

可以使用列舉的ordinal方法獲取到該列舉常量在列舉中的排列位置，但依賴該方法的話維護就會很麻煩；比如新增一個列舉或重排，就會導致該位置發生變化。
所以永遠不要根據列舉的序數匯出與它關聯的值，而是使用列舉值的成員變數來儲存，通過構造方法傳入。
最好完全避免使用ordinal方法，它是設計成用在EnumSet、EnumMap這種基於列舉的通用資料結構的。

32. 用EnumSet代替位域

/*
    使用int常量進行位運算，位域
*/
public class Text {
    public static final int STYLE_BOLD = 1 << 0;
    public static final int STYLE_ITALIC = 1 << 2;
    public static final int STYLE_UNDERLINE = 1 << 3;

    public void applyStyles(int styles) {
    }

    //text.applyStyles(STYLE_BOLD | STYLE_ITALIC);
}

/*
  使用EnumSet代替位域
*/
public class TextEnumSetStyle {
    public enum Style {
        BOLD, ITALIC, UNDERLINE;
    }

    public void applyStyles(Set<Style> styles) { //使用介面接收，說不定傳其他的Set實現
    }

    //text.applyStyles(EnumSet.of(Style.BOLD,Style.ITALIC));
}

• 位域有著int列舉常量的所有缺點，不能列印、不能遍歷等

• EnumSet實現了Set介面，提供了豐富的功能和型別安全性，以及可以從其他任何Set實現中得到的互用性。
  在內部實現上，每個EnumSet內容都表示為向量；如果列舉型別<=64個，整個EnumSet就是用單個long來表示，所以效能比得上位域。

EnumSet類集位域的簡潔和效能優勢、及列舉型別的所有優點於一身，但列舉本身是消耗效能的，使用時考慮考慮。

33. 使用EnumMap代替序數索引

• EnumMap的執行速度方面可以與使用序數的程式相媲美，它沒有不安全的轉換；不必通過索引輸出。

• EnumMap在內部使用了陣列， 索引執行速度和通過序數索引的陣列一樣。
  EnumMap構造器採用的鍵型別是Class物件：有限制的型別令牌(bounded type token)，它提供了執行時的泛型資訊。

EnumMap使用Enum作為鍵，值可為任意。當你需要使用Enum時，並且需要通過該列舉型別作為序數索引時，就考慮使用EnumMap。

34. 用介面模擬可伸縮的列舉

• 讓列舉實現介面來擴充套件列舉。

• 用介面來擴充套件列舉的缺點是：列舉無法繼承，所以程式碼不能複用；少量的可以複製貼上，但如果有大量的共享程式碼，則可以封裝在一個輔助類或靜態輔助方法中。

雖然無法編寫可擴充套件的列舉型別，卻可以通過編寫介面以及實現該介面的基礎列舉型別，對它進行模擬。這樣執行客戶端編寫自己的列舉來實現介面。

35. 註解優先於命名模式

舉例：JUnit測試框架原本要求它的使用者一定要用test作為測試方法開頭，後來改成使用註解標明。

• 命名模式的缺點：
  
  1. 文字拼寫錯誤會導致失敗，且沒有任何提示
  2. 無法確保它們只用於相應的程式元素上，比如該用在方法上卻用在類上。
  3. 它們沒有提供將引數值和程式元素關聯起來的好方法。

註解很好的解決所有這些問題。

• 註解中陣列引數的語法十分靈活，它是進行過優化的單元素陣列。

//@Target(ElementType.Method)  
 //@Retention(RetentionPolicy.RUNTIME)
  public @interface MyAnnotation {
     String[] value() default ""; 
  }

使用時@MyAnnotation({"1","2"})來宣告引數。

在編寫框架時，比如JUnit、ButterKnife之類的註解框架，可以有效的使用註解來解耦、提高效能，應該避免使用命名模式。

36. 堅持使用Override註解

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}

@Override註解只能用在方法宣告上，表示被註解的方法覆蓋了父類中的一個方法。

• 應該在你想要覆蓋超類方法的每個方法宣告中使用Override註解。可以避免把覆蓋誤用成過載。這是利用了註解編譯期進行檢查的功能。IDE也會提示你進行了錯誤的覆蓋。

• 在抽象類或者介面中，應當標註所有你想要的方法，來覆蓋超類或者介面的方法，無論是具體的還是抽象的。

37. 用標記介面定義型別

標記介面(marker interface)是沒有包含方法宣告的介面，而只是指明一個類實現了具有某種屬性的介面。

• 標記介面勝於標記註解

  1. 標記介面定義的型別是由被標記類的例項實現的，標記註解則沒有定義這樣的型別；這個型別可以捕捉到編譯期間的錯誤，而標註註解可能要在執行時才能發現。
  2. 標記介面可以被更精確的鎖定。
     例如Set介面是Collection介面的子型別，雖然它不是標記介面，但可以說成是有限制的標記介面。這種標記介面可以描述整個物件的某個約束條件(例如Set)，或者表明例項能夠利用其它每個類的方法進行處理(例如ObjectOutputStream需要Serializable介面進行標記)。

• 標記註解勝於標記介面

  1. 標記註解可以通過預設的方式新增一個或多個註解型別元素，給已被使用的註解型別新增更多的資訊。即簡單的標記註解型別可以演變成更加豐富的註解型別。這對於標記介面則是不可能的，因為標記介面不能在實現它了之後再隨意新增方法
  2. 標記註解的另一個優點在於它是更大的註解機制的一部分。因此標記註解在那些大量使用註解的框架中具有一致性。

• 什麼時候用標記介面、標記註解呢，在寫程式碼時可以多考慮考慮
  如果標記是應用到任何元素時，使用標記註解；
  如果只用於類和介面，就要考慮這個被標記的類的例項所用的地方多不多？

  • 如果多，使用標記介面就可以傳入該介面型別，做到編譯期進行檢查。
  • 如果不多，就再考慮是否永遠限制這個標記只用於特殊類、介面麼？如果是永遠限制，就做成一個介面的子介面進行限制；如果不是永遠限制，就可以使用標記註解。

標記介面和標記註解都各有用處：
如果想要定義一個任何新方法都不會與之關聯的型別，標記介面就是最好的選擇；
如果該標記在未來可能要給標記新增更多的資訊，或者標記要適合於已經廣泛使用了註解型別的框架，那麼就選擇標記註解。