有一次小明传数据给我，把我弄哭了

某天小明处理的一些数据需要传给我这边处理，于是小明在我们的传输媒介上面新增了一个 Map 用于保存这些数据，数据结构如下：

public class Record {
  private final Map<String, String> extData = new HashMap<>();
  public void setData(String key, String data) {
    extData.put(key, data);
  }
  public String getData(String key) {
    return extData.get(key);
  }
}

在小明猛如虎的一顿操作之下，告诉我数据已经放在 Record#extData 中了，自己调方法拿就好了，Map 的 Key 值就是 xxx 中的某个值，我一听懵了，我去哪找这个 Key 啊，得多费劲啊，都把我弄哭了。

于是，小明看出了我心里的憋屈，在项目的常量类中将相关的 Key 写成了常量的形式：

public class Constants {
  public static final String KEY_1 = "key1";
  public static final String KEY_2 = "key2";
  public static final String KEY_3 = "key3";
}

于是我又得去找这个常量类中相关的 Key，但是相比之前，情况已经好很多了，把 Key 限定在了某个常量类中的某几个常量中。

但问题来了，只有我和小明知道我们之间的约定，那么如果有另外一个人去获取小明的 extData 数据呢？是不是又得问小明一遍？那小明得多忙啊？而且有些人就懒得问了，直接凭着自己的理解，传一个自己“参悟”得到的 Key 来获取 extData，这时很可能就跟小明给的不一样，导致数据获取不了。

于是小明特地为 extData 这个 Map 的 Key 定义了一个枚举，将 Key 定义到这个枚举上面：

public enum KeyEnum {
  KEY_1,
  KEY_2,
  KEY_3
}

接着在 getter、setter 方法上面将 Key 的类型改成 Key 的枚举类型，在将 extData 的 Map 类型改成 EnumMap ：

public class Record {
  private final Map<KeyEnum, String> extData = new EnumMap<>(KeyEnum.class);
  public void setData(KeyEnum keyEnum, String data) {
    extData.put(keyEnum, data);
  }
  public String getData(KeyEnum keyEnum) {
    return extData.get(keyEnum);
  }
}

据说，小明改完之后，终于没人再来打扰他安静写代码了！

以上的问题看着很简单，但是很多开发人员都干过类似的事：我写的代码你猜对了算我输，爽了自己，让别人去猜吧。

比如某个业务中的一个数组，数组下标对应一些跟业务相关的值，最好的做法就是创建一个下标值的枚举或者常量，然后根据枚举或者常量去获取，不然你在项目中直接写个需要，天知道你这个序号代表的是个啥意思啊！

很多人不太关注如何给项目定义常量、枚举这些东西，认为写多一个类多麻烦啊，导致项目中满天飞的字符串，维护起来特别费劲，而且还要经常猜作者的意思，还容易出错！

我们都应该要养成良好的编码习惯，学会如何优雅地写代码，常量枚举大胆用起来！