摘要：常量接口是對接口的一種不良使用。如果這些常量最好被看作是枚舉類型成員，那就應該用枚舉類型來導出。因為客戶端既不能創建枚舉類型的實例，也不能對它進行擴展，因此很可能沒有實例，而只有聲明過的枚舉常量。換句話說，枚舉類型是實例受控的。

我們偶爾能在項目中看到如下風格的代碼：

public class ResponseCode {
    public static final int SUCCESS = 0;
    public static final int FAILURE = 10000;
    public static final int ILLEGAL_ARGUMENT = 10001;
    //........
}

這樣的代碼一般被叫做int枚舉模式。其包含著大量缺點：

int枚舉是編譯時常量，被編譯到客戶端中，如果枚舉常量關聯的int發生變化，客戶端必須重新編譯，如果沒有重新編譯，程序仍可以運行，但行為就不確定了。

將int枚舉常量翻譯成可打印的字符串很麻煩。

在本例中，我要向客戶端返回一個錯誤碼和錯誤信息，錯誤碼可以通過ResponseCode.FAILURE獲得，但是錯誤信息恐怕只能以"FAILURE"這樣的hard code返回了。

遍歷一個組中所有的int枚舉常量，獲得int枚舉組的大小，沒有可靠的方法。

在這種int枚舉模式的基礎上，還有一種變體，我們稱之為String枚舉模式。雖然它提供了可打印的字符串，但這種方式存在性能問題，因為依賴于字符串的比較操作。

還有一種代碼類似：

public interface CascadeConstant {
    String DELETION_CHECK_CODE = "deletion.check";
    String DELETION_DELETE_CODE = "deletion.delete";
    String DELETION_FORCE_DELETE_CODE = "deletion.forceDelete";
    String DELETION_CLEANUP_CODE = "deletion.cleanup";

    List DELETION_CODES = Arrays.asList(DELETION_CHECK_CODE, DELETION_DELETE_CODE, DELETION_FORCE_DELETE_CODE);
}

這樣的代碼我們一般稱之為常量接口(constant interface)——這種接口不包含任何方法，它只包含靜態的final域，每個域都導出一個常量。

類實現接口時，接口就充當可以引用這個類的實例類型。因此，類實現了接口，就表明客戶端對這個類的實例可以實施某些動作。為了任何其他目的而定義的接口是不恰當的。

?常量接口是對接口的一種不良使用。類在內部使用某些常量，純粹是實現細節，實現常量接口，會導致把這樣的實現細節泄露到該類的導出API中，因為接口中所有的域都是及方法public的。類實現常量接口，這對于這個類的用戶來講并沒有實際的價值。實際上，這樣做返回會讓他們感到更糊涂，這還代表了一種承諾：如果在將來的發行版本中，這個類被修改了，它不再需要使用這些常量了，依然必須實現這個接口，以確保二進制兼容性。如果非final類實現了常量接口，它的所有子類的命名空間都受到了污染。Java平臺類庫中存在幾個常量接口，如java.io.ObjectStreamConstants，這些接口都是反面典型，不值得效仿。

那既然不適合存在全部都是導出常量的常量接口，那么如果需要導出常量，它們應該放在哪里呢？如果這些常量與某些現有的類或者接口緊密相關，就應該把這些常量添加到這個類或者接口中，注意，這里說添加到接口中并不是指的常量接口。在Java平臺類庫中所有的數值包裝類都導出MIN_VALUE和MAX_VALUE常量。如果這些常量最好被看作是枚舉類型成員，那就應該用枚舉類型來導出。否則，應該使用不可實例化的工具類來導出這些常量。

我們先看改良版的ResponseCode ：

public enum ResponseCode {
    SUCCESS(0),
    ERROR(10000),
    ILLEGAL_ARGUMENT(10001);

    private final int code;

    ResponseCode(int code) {
        this.code = code;
    }

    public int getCode() {
        return code;
    }

    public static ResponseCode getEnum(int value) {
        for (ResponseCode responseCode : ResponseCode.values()) {
            if (responseCode.getCode()==value) {
                return responseCode;
            }
        }
        return null;
    }
}

這樣就克服了我們之前提到的缺點：類型確定。
在int枚舉模式中或者String枚舉模式中，我們會寫出這樣的方法簽名：

//int 枚舉模式
SendResponse(String description,int value)
//String枚舉模式
//SendResponse(String description,int value)

這樣的代碼其實并不可靠，我們可以考慮：

SendResponse(String description,int code)

那么在調用的時候實質上是：

SendResponse(ResponseCode.ERROR.toString(),ResponseCode.ERROR.getCode())

為了更加方便，我們可以在此之上簡單的封裝一層：

AutoBuildAndSendResponse(ResponseCode responseCode){
  SendResponse(responseCode.toString(),responseCode.getCode();
}

這就很美滋滋。

在這個情況下，我們甚至還可以考慮在SendResponse方法中再加一個名為errorDetail的參數。利用方法重載，使Reponse的返回信息更為靈活。

不僅如此，Java的枚舉類是很強大的。其本質是int值，并且背后基本原理也非常簡單：它們就是通過共有的靜態final域為每個枚舉常量導出實例的類。因為沒有可以訪問的構造器，枚舉類是真正的final。因為客戶端既不能創建枚舉類型的實例，也不能對它進行擴展，因此很可能沒有實例，而只有聲明過的枚舉常量。換句話說，枚舉類型是實例受控的。而且，Java的枚舉類還可以添加任意的方法和域，并實現任意接口，而且也提供了所有的Object方法的高級實現。

public enum SourceDiskType {

    SYSTEM("system"),
    DATA("data"),;

    private String stringValue;

    SourceDiskType(String stringValue) {
        setStringValue(stringValue);
    }

    public String getStringValue() {
        return stringValue;
    }

    public void setStringValue(String stringValue) {
        this.stringValue = stringValue;
    }

    public static SourceDiskType getEnum(String stringValue) {
        if (null == stringValue) {
            return null;
        }

        for (SourceDiskType sourceDiskType : SourceDiskType.values()) {
            if (sourceDiskType.getStringValue().equals(stringValue)) {
                return sourceDiskType;
            }
        }
        return null;
    }
}

這是阿里云早期版本SDK中的一段代碼。