为什么建议使用对象来替换枚举？
在设计模型时，我们经常会使用枚举来定义类型，比如说，一个员工类 Employee，他有职级，比如P6/P7。顺着这个思路，设计一个 Level 类型的枚举：
代码语言：javascript复制class Employee {
private String name;
/**
* 薪水
*/
private int salary;
/**
* 工龄
*/
private int workAge;
/**
* 职级
*/
private Level level;
}
enum Level {
P6, P7;
}假设哪天悲催的打工人毕业了，需要计算赔偿金，简单算法赔偿金=工资*工龄
代码语言：javascript复制 class EmployeeService {
public int calculateIndemnity(int employeeId) {
Employee employee=getEmployeeById(employeeId);
return employee.workAge * employee.salary;
}
}后来，随着这块业务逻辑的演进，其实公司是家具备人文关怀的好公司，再原有基础上，按照职级再额外补发一定的金额：
代码语言：javascript复制public int calculateIndemnity(int employeeId) {
Employee employee = getEmployeeById(employeeId);
switch (employee.level) {
case P6:
return employee.workAge * employee.salary 10000;
break;
case P7:
return employee.workAge * employee.salary 20000;
break;
default:
throw new UnsupportedOperationException("");
}
}当然，这段逻辑可能被重复定义，有可能散落在各个Service。 这里就出现了「代码的坏味道」 新的枚举值出现怎么办？ 显然，添加一个新的枚举值是非常痛苦的，特别通过 switch 来控制流程，需要每一处都修改枚举，这也不符合开闭原则。而且，即使不修改，默认的防御性手段也会让那个新的枚举值将会抛出一个异常。
为什么会出现这种问题？ 是因为我们定义的枚举是简单类型，无状态。
这个时候，需要用重新去审视模型，这也是为什么 DDD 是用来解决「大泥球」代码的利器。 一种好的实现方式是枚举升级为枚举类，通过设计「值对象」来重新建模员工等级：
代码语言：javascript复制abstract class EmployeeLevel {
public static final EmployeeLevel P_6 = new P6EmployeeLevel(6, "资深开发");
public static final EmployeeLevel P_7 = new P7EmployeeLevel(7, "技术专家");
private int levle;
private String desc;
public EmployeeLevel(int levle, String desc) {
this.levle = levle;
this.desc = desc;
}
abstract int bouns();
}
class P6EmployeeLevel extends EmployeeLevel {
public P6EmployeeLevel(int level, String desc) {
super(level, desc);
}
@Override
int bouns() {
return 10000;
}
}
static class P7EmployeeLevel extends EmployeeLevel {
public P7EmployeeLevel(int level, String desc) {
super(level, desc);
}
@Override
int bouns() {
return 20000;
}
}你看，这里叫「EmployeeLevel」，不是原先的「Level」，这名字可不是瞎取的。 这里，我把 EmployeeLevel 视为值类型，因为： ● 不可变的 ● 不具备唯一性 通过升级之后的模型，可以把员工视为一个领域实体 Employee：
代码语言：javascript复制class Employee {
private String name;
/**
* 薪水
*/
private int salary;
/**
* 工龄
*/
private int workAge;
/**
* 职级
*/
private EmployeeLevel employeeLevel;
public int calculateIndemnity() {
return this.workAge * this.salary employeeLevel.bouns();
}
}可以看到，计算赔偿金已经完全内聚到 Employee 实体中，我们设计领域实体的一个准则是：必须是稳定的，要符合高内聚，同时对扩展是开放的，对修改是关闭的。你看，哪天 P8 被裁了，calculateIndemnity 是一致的算法。 当然，并不是强求你把所有的枚举都替换成类模型来定义，这不是绝对的。还是要按照具体的业务逻辑来处理。
