关于常量，枚举和注解

我们在开发时候，难免需要定义一些常量，例如我们定义用户的性别的时候，会有男和女，类似下面的

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);
}

后记

写这样的事情，其实应为看多了，很多都是才用写常量的第一种方案来做，感觉不是很好，所以就罗嗦的写这么一篇出来。虽然我们很多知道注解的意思和用法，但有时并没有被合理的运用到应该的位置。