如何规范化Enum在项目中的使用？

前言

在我们平时开发过程中，枚举的使用时必不可少的。

为什么要用枚举？有穷序列的字段用int或tinyint不是挺好吗？

答案很简单：我们的程序写给人看的。

既然是写给人看，那么，可理解、易理解往往显得相当重要！

枚举一般有两部分，一个是枚举项值，一个是枚举描述。那么，这两个属性怎么命名呢？code和desc？还是value和desc？还是key和value？

一位架构师强调过：对于企业应用系统，当前的硬件资源和技术条件已经很给力了，通常情况下，我们大可不必为了追求性能而将类型、状态等字段定义成数字类型；而编写易理解、可维护的系统，已经越发显得重要了。将这些字段定义成字符串类型，用字符串来描述字段值，就是易理解的一个重要体现。

随着项目的不断开发迭代，大家在项目里定义的枚举越来越多。这些枚举类的结构很相同，不同之处仅仅是各枚举项。另外，在对枚举的使用方面也五花八门，毕竟每个人对技术的理解和认知甚至工作态度是不同的。

常用案例一

添加图片注释，不超过 140 字（可选）

常用案例二

添加图片注释，不超过 140 字（可选）

常用案例三

添加图片注释，不超过 140 字（可选）

常用案例四

添加图片注释，不超过 140 字（可选）

优化方案

站在团队开发规范的角度上思考，能否为这些枚举定义统一的接口，这样，大家在使用的时候就更统一了。

添加图片注释，不超过 140 字（可选）

同时，还定义了一个工具方法，用来根据code来获取对应的枚举项：

添加图片注释，不超过 140 字（可选）

优化后案例一

添加图片注释，不超过 140 字（可选）

优化后案例二

添加图片注释，不超过 140 字（可选）

优化后案例三

添加图片注释，不超过 140 字（可选）

优化后案例四

添加图片注释，不超过 140 字（可选）

总结

这样就可以对enum枚举做了规范，在使用的时候都是统一的方式，而且又可以非常灵活的让业务系统自定义