简单来说，enum这个东西不OO。
使用enum意味着我们要区分两个不同的东西，但如果这两个东西不同，那么就应该给这两个东西分别创建class，既然是class了，那么这2个东西就由它们class的名字来区别，而class的名字也就是它们的类型。
举一个例子，比如我要写一个自定义Exception的体制，我可能要自定义多种Exception。
一种写法是我先写一个Exception基类，然后其他Exception都继承自这个Exception基类，甚至Exception间还有多级继承关系。
另一种写法是我只有一个Exception类，但这个类里面加了一个enum来说明到底是哪种Exception。
初看貌似后一种写法更简单，不需要写一堆duplicate的class，但如果你是一门语言的设计者，你会怎么选择呢。
目前我已知的所有语言，都是选择了第一种也就是基类的做法。
为什么会这样呢？我们可以考察一下如果一段code里同时可能抛出两种Exception，将会发生什么。
第一种写法，我可以加catch block，每个catch block可以精确捕捉需要的Exception 子类。
第二种写法，我只能有一个catch block去捕捉唯一的Exception，然后在catch block内部用多个if else去判断那个enum到底是哪个Exception。
显然，第二种写法很快就会让那个唯一的catch block里的代码变得不可控。
总而言之，第一种写法在class这个level抽象，第二种写法在method这个level抽象，而class是比method更高一个level的抽象。
如果我们选择较低level的抽象，可以获得相对简单的设计，但是丧失了以后变化的可能性，最终将要付出更多的代价。
所以无论何时，我们都应该首先在class level的抽象上思考问题。
很多码农一上来就是：这个东西太麻烦了，我这么改一下更简单。
但其实，要敲的代码行数是最不用考虑的事情，如果一个东西仅靠按照follow同一个pattern不停的堆代码就能完成，那这个东西其实是个最简单的东西。
而我们做架构的任务就是要把复杂的东西变成只要follow pattern无脑堆代码就能解决的东西。
竟然还有程序员嫌弃要写的代码太多了。