Java接口返回值為什么不使用枚舉

比如星巴克提供了 0.0.1 版本的二方庫(kù)，定義了一個(gè) Starbucks 類(lèi)，里面包含了枚舉類(lèi)型的 SizeEnum，里面分別是中杯、大杯、特大杯。

public class Starbucks implements Serializable {
  private Long id;
  private String name;
  private Integer capacity;
  private SizeEnum sizeEum;
}

public enum SizeEnum {
  TALL(1),
  GRANDE(2),
  VENTI(3)
}

定義了一個(gè)服務(wù)類(lèi)，實(shí)現(xiàn)了根據(jù) id 獲取星巴克的方法：

public class StarbucksImpl implements StarbucksService {
  public Starbucks getStarbucksById(Long id) {
    Starbucks starbucks = new Starbucks();
    starbucks.setId(1L);
    starbucks.setName("Latte");
    starbucks.setCapacity(360);
    starbucks.setSizeEnum(SizeEnum.TALL);
    return starbucks;
  }
}

然后，星巴克的門(mén)店引入 0.0.1 這個(gè)版本 jar 包，然后賣(mài)的好好的：

public class StarbucksDemo {
  @Resource
  private StarbucksService starbucksService;
  
  public void getStarbucks() {
    Starbucks starbucks = starbucksService.getStarbucksById(1L);
    System.out.println(starbucks);
  }
}

有一天，老羅說(shuō)要那個(gè)中等大小的中杯拿鐵，但是服務(wù)員說(shuō)那是大杯，經(jīng)過(guò)一番爭(zhēng)論，羅老師很是生氣。

于是星巴克升級(jí)到了 0.0.2 版本二方庫(kù)，在枚舉類(lèi) SizeEnum 中新增了小杯，升級(jí)后的枚舉類(lèi)如下：

public enum SizeEnum {
  TALL(1),
  GRANDE(2),
  VENTI(3),
  SHORT(4)
}

同時(shí)服務(wù)類(lèi)的接口方法也做了相應(yīng)修改：

public class StarbucksImpl implements StarbucksService {
  public Starbucks getStarbucksById(Long id) {
    Starbucks starbucks = new Starbucks();
    starbucks.setId(1L);
    starbucks.setName("Latte");
    starbucks.setCapacity(240);
    starbucks.setSizeEnum(SizeEnum.SHORT);
    return starbucks;
  }
}

由于星巴克的門(mén)店比較多，有的還不知道這個(gè)新加的需求，因此返回結(jié)果中出現(xiàn)了 SHORT，但是 0.0.1 版本的二方庫(kù)中沒(méi)有小杯啊，所以就出問(wèn)題了，也就是序列化失敗。

通過(guò)這個(gè)例子，我相信大家對(duì)枚舉類(lèi)型作為返回結(jié)果有了一定的理解，下面引用孤盡大佬在知乎的回答：

由于升級(jí)原因，導(dǎo)致雙方的枚舉類(lèi)不盡相同，在接口解析，類(lèi)反序列化時(shí)出現(xiàn)異常。

Java 中出現(xiàn)的任何元素，在 Gosling 的角度都會(huì)有背后的思考和邏輯（盡管并非絕對(duì)完美，但 Java 的頂層抽象已經(jīng)是天才級(jí)了），比如：接口、抽象類(lèi)、注解、和本文提到的枚舉。枚舉有好處，類(lèi)型安全，清晰直接，還可以使用等號(hào)來(lái)判斷，也可以用在 switch 中。它的劣勢(shì)也是明顯的，就是不要擴(kuò)展?？墒菫槭裁丛诜祷刂岛蛥?shù)進(jìn)行了區(qū)分呢，如果不兼容，那么兩個(gè)都有問(wèn)題，怎么允許參數(shù)可以有枚舉。當(dāng)時(shí)的考慮，如果參數(shù)也不能用，那么枚舉幾乎無(wú)用武之地了。參數(shù)輸出，畢竟是本地決定的，你本地有的，傳送過(guò)去，向前兼容是不會(huì)有問(wèn)題的。但如果是接口返回，就比較惡心了，因?yàn)榻馕龌貋?lái)的這個(gè)枚舉值，可能本地還沒(méi)有，這時(shí)就會(huì)拋出序列化異常。

比如：你的本地枚舉類(lèi)，有一個(gè)天氣 Enum：SUNNY, RAINY, CLOUDY，如果根據(jù)天氣計(jì)算心情的方法：guess(WeatcherEnum xx)，傳入這三個(gè)值都是可以的。返回值：Weather guess(參數(shù))，那么對(duì)方運(yùn)算后，返回一個(gè) SNOWY，本地枚舉里沒(méi)有這個(gè)值，傻眼了。