關於常量，枚舉和註解

我們在開發時候，難免需要定義一些常量，例如我們定義用戶的性別的時候，會有男和女，類似下面的

public class User {

       public static final int GENDER_MALE=0;
       public static final int GENDER_FEMALE=1;

       int gender;

        public int getGender() {
            return gender;
        }

        public void setGender(int gender) {
            this.gender = gender;
        }

}

使用的時候也很自然的使用，類似這樣mUser.setGender(User.GENDER_MALE),我們在和服務器獲取數據時候，也可以簡單的做Json裝換。
但這樣些有些小問題，有時候可能有些人對業務不是很熟悉，所以會寫些別的數字進去之類的錯誤！類似這樣：mUser.setGender(-1)，當然這個例子所體現的可能不是很好的表達情景，但希望你get到。

爲了規避這類問題，有的使用枚舉來做 ,寫成下面這樣

public Gender gender;

public enum Gender {
    MALE,
    FEMALE;

    Gender() {
    }
}

但這個有一個小問題，我們的服務器傳過來的數據，例如Json格式的時候，這個裝換就不是很容易了，當然除此之外還有存儲和修改帶來的問題。
顯然這兩種方案，用常量和枚舉都不是很好的解決我們的需要。
而且，有時候我們還會對傳進來的參數做一個檢測，看是不是傳對值得，類似這樣的情況情況，還需要寫不少檢測代碼，判斷傳進來的值是否爲合理的參數。

合理的設計是避免問題的發生
一個例子就是飛機上的馬桶的出水按鈕，他被設計在很彆扭的位置，需要用戶挪動下，纔可以按到，這麼設計是因爲有些人，一按，水一衝，負壓下，那人就會被“吸住”，黏在馬桶上，結果需要很多人來拉動，才能脫離馬桶，這真的很尷尬。所以後來馬桶的設計就把出水的按鈕改到一個需要較遠需要用戶挪動身子的位置，從而避免被吸住。

我們也應該儘量去做到，所以針對這類問題，我們需要運用下註解

我們的銀彈 —— 註解@

使用註解的方式，可以幫助我們避免上面提到的問題，我們自己寫一個性別的註解，然後加在設置性別的前面。就像下面這樣

/**{ @hide }*/
@IntDef(flag = true,
        value = {
                GENDER_MALE,
                GENDER_FEMALE
        })
@Retention(RetentionPolicy.SOURCE)
public @interface Gender {
}


public static final int GENDER_MALE = 1;
public static final int GENDER_FEMALE = 2;
int gender;

public void setGender(@Gender int gender) {
    this.gender = gender;
}

通過這樣的方式，我們就可以確保別的人員不會亂輸入值，因爲程序會自動幫我們做檢測。

例如像這樣寫mUser.setGender(1)的話，我們會得到這麼句話。
提示我們只能是下面其中的一個的值:UserBean.GENDER_MALE, UserBean.GENDER_FEMALE

Must be one or more of: UserBean.GENDER_MALE, UserBean.GENDER_FEMALE
less… (Ctrl+F1)

This inspection looks at Android API calls and ensures that the
correct type of resource is passed to an int-parameter expecting
resources of a given type; it checks that APIs which expect an RGB
color integer are passed actual colors rather than color resources; it
checks that APIs which require a certain permission have the
permission declared in the manifest; it checks that parameters
expected to fall within a given range actually do; it checks that
results of certain method calls are looked at by the caller, and so
on.

這樣的小技巧顯然可以幫助我們避免一個潛在的問題，同時也更規範的。
在Android中也大量的充斥着這類用法，例如我們的PendingIntent。
我們使用PendingIntent.getActivity（this，0，mIntent，156）;，
查看源碼我們可以看到下面這樣的一個註解@Flags，所以當我亂填一個156後，就會有錯誤提示。

public static PendingIntent getActivity(Context context, int requestCode,
            Intent intent, @Flags int flags) {
        return getActivity(context, requestCode, intent, flags, null);
    }

---

後記

寫這樣的事情，其實應爲看多了，很多都是才用寫常量的第一種方案來做，感覺不是很好，所以就羅嗦的寫這麼一篇出來。雖然我們很多知道註解的意思和用法，但有時並沒有被合理的運用到應該的位置。