枚举很好用啊！为啥阿里不建议返回值用枚举？？
来自：zhihu.com/question/52760637
提问
小伙伴说在一次接口定义时，使用了枚举，结果被其它人深深嫌弃，说不好拓展。 为什么会被嫌弃呢？我们先来看看阿里开发手册关于枚举使用的建议 
从手册可以看出，定义和使用枚举，阿里开发手册都是支持的，但是为啥，返回值就要反对了呢？ 看看作者孤尽是怎么说的
由于升级原因，导致双方的枚举类不尽相同，在接口解析，类反序列化时出现异常。Java中出现的任何元素，在Gosling的角度都会有背后的思考和逻辑（尽管并非绝对完美，但Java的顶层抽象已经是天才级了），比如：接口、抽象类、注解、和本文提到的枚举。 枚举有好处，类型安全，清晰直接，还可以使用等号来判断，也可以用在switch中。 它的劣势也是明显的，就是不能扩展。可是为什么在返回值和参数进行了区分呢，如果不兼容，那么两个都有问题，怎么允许参数可以有枚举。当时的考虑，如果参数也不能用，那么枚举几乎无用武之地了。 参数输出，毕竟是本地决定的，你本地有的，传送过去，向前兼容是不会有问题的。 但如果是接口返回，就比较恶心了，因为解析回来的这个枚举值，可能本地还没有，这时就会抛出序列化异常。 比如：你的本地枚举类，有一个天气 Enum：SUNNY, RAINY, CLOUDY，如果根据天气计算心情的方法：guess(WeatcherEnum xx)，传入这三个值都是可以的。 返回值：Weather guess(参数)，那么对方运算后，返回一个SNOWY，本地枚举里没有这个值，傻眼了。 不过，另一位网友Brian的回答也很通俗易懂
枚举，就是把已知的全部罗列出来。作为二方/三方库的提供者，我支持什么，你们就是用什么，这样是安全的。 库版本升级后我支持了更多，你不知道情况下自然不会使用，反正我不支持的参数你不可能传递给我，所以作为输入，枚举简直就是安全保障。 但作为返回值，情况就反过来了。 我先告诉你这些这些可以有，然后你规定这些这些可以有，除此之外都没有。但是，是我说了算而不是你，所以你的规定狗屁不是。 没有仔细看手册(假设有的话)的每一个字，鬼知道升级后的api会返回什么，抛异常的可能性直趋百分百。
PS：如果觉得我的分享不错，欢迎大家随手点赞、转发、在看。
来自：zhihu.com/question/52760637
提问
小伙伴说在一次接口定义时，使用了枚举，结果被其它人深深嫌弃，说不好拓展。 为什么会被嫌弃呢？我们先来看看阿里开发手册关于枚举使用的建议 从手册可以看出，定义和使用枚举，阿里开发手册都是支持的，但是为啥，返回值就要反对了呢？ 看看作者孤尽是怎么说的
由于升级原因，导致双方的枚举类不尽相同，在接口解析，类反序列化时出现异常。Java中出现的任何元素，在Gosling的角度都会有背后的思考和逻辑（尽管并非绝对完美，但Java的顶层抽象已经是天才级了），比如：接口、抽象类、注解、和本文提到的枚举。 枚举有好处，类型安全，清晰直接，还可以使用等号来判断，也可以用在switch中。 它的劣势也是明显的，就是不能扩展。可是为什么在返回值和参数进行了区分呢，如果不兼容，那么两个都有问题，怎么允许参数可以有枚举。当时的考虑，如果参数也不能用，那么枚举几乎无用武之地了。 参数输出，毕竟是本地决定的，你本地有的，传送过去，向前兼容是不会有问题的。 但如果是接口返回，就比较恶心了，因为解析回来的这个枚举值，可能本地还没有，这时就会抛出序列化异常。 比如：你的本地枚举类，有一个天气 Enum：SUNNY, RAINY, CLOUDY，如果根据天气计算心情的方法：guess(WeatcherEnum xx)，传入这三个值都是可以的。 返回值：Weather guess(参数)，那么对方运算后，返回一个SNOWY，本地枚举里没有这个值，傻眼了。 不过，另一位网友Brian的回答也很通俗易懂
枚举，就是把已知的全部罗列出来。作为二方/三方库的提供者，我支持什么，你们就是用什么，这样是安全的。 库版本升级后我支持了更多，你不知道情况下自然不会使用，反正我不支持的参数你不可能传递给我，所以作为输入，枚举简直就是安全保障。 但作为返回值，情况就反过来了。 我先告诉你这些这些可以有，然后你规定这些这些可以有，除此之外都没有。但是，是我说了算而不是你，所以你的规定狗屁不是。 没有仔细看手册(假设有的话)的每一个字，鬼知道升级后的api会返回什么，抛异常的可能性直趋百分百。
PS：如果觉得我的分享不错，欢迎大家随手点赞、转发、在看。
评论