最近新入职，参与到一个项目中，另我感到奇怪的是项目中定义的所有枚举都毫无例外的加上了一个整型属性code。当这些枚举被使用时也是通过判断code来确定属于哪一个枚举实例，这就相当于把枚举实例当成了普通类的实例来使用了。
这样就失去了使用枚举最大的乐趣和好处了，枚举实例本身是具备自注释的能力的，也就是枚举值的字面量。列如说一个订单对象的状态，可能有“初始化”，“已支付”，“已完结”。此时使用一个枚举OrderStatus来定义这几个状态，他有几个字面量为“INIT”，“PAID”，“FINISHED”的实例。正常在你的业务层，你直接使用这些对象即可，显得清晰简练。为什么非要额外加一个code呢？有小伙伴说，由于这个状态要落库，用枚举的字面量入库会浪费数据库空间，又有小伙伴说了由于上下游之间传递字面量，如果上游新增枚举值，下游没有跟上就会出现错误。我们假设这两个观点都有道理，那么我们就非要在全局都使用属性code来判定状态么？当你看到OrderStatus.INIT.getCode时有没有觉得后面的getCode是多余的？实例本身已然可以告知我们状态了，何必再去调用一个方法呢？如果小伙伴们提的理由都成立那么我们可以在入库之前和传递给下游的报文中使用code属性，也没必要在自己的业务流程中也用code不是？实则这两个理由我并不十分赞同，在情况允许的时候直接存储或传输字面量也是不错的选择。第一通过数字来区分，表面上看省了点空间可是时间一长，状态在需求变更过程中会增添，那么就会出现你维护的code不再连续了，你原来定义的1，2，3，4，可能变成了1，2，5，8。这就让人迷惑了，当然对于大部分人来说这没什么大不了的。当你把这些“魔鬼数字”落库或者传给下游时它也就失去自注释的功能。下游系统可能有两种做法来对付你的魔鬼数字。第一种，他利用你的code又另外定义了一个枚举，第二种他直接定义常量。无论哪一种明智的他必定会在收到你的报文第一时间转换成他的枚举对象或者常量由于他不想让这样的魔鬼数字或者get**也贯穿到他的代码里。那么他势必要在他的枚举定义里写上转换方法或者其他什么地方写转换方法。此时如果你传给他的是字面量，他就不再需要这个额外的方法了，由于我们都知道枚举本身带的valueOf方法可以将字面量还原为枚举对象，当然你要捕获异常，防止上游传给你不认识的字面量。小伙伴说你看这就有风险了如果人家没捕获呢？那如果是数字难道说你不用假设有不认识的数字？所以多捕获一个异常带来全局的可读性和代码的简练我认为这是值得的。对于数据库，我想如果你的数据量不是太大多出来的几个字节能给你带来编码上的便利也不是不可选择。有人说长字面量维护索引也会增加存储（B树索引），实则枚举型字段是不适合建索引的，这是另一个话题。目前传统关系型数据库的使用有一个趋势就是数量维持在必定范围内。大数据量的查询交给了ES，DB2等存储系统。即便如此我们也只需要在写库读库时使用函数转换字面量即可，犯不上整个系统都贯穿get**或者魔鬼数字。总之别忘了枚举自带的valueOf和name
- 最新
- 最热
只看作者