代码的坏味道(二)——为什么建议使用模型来替换枚举?

为什么建议使用对象来替换枚举?

在设计模型时,我们经常会使用枚举来定义类型,比如说,一个员工类 Employee,他有职级,比如P6/P7。顺着这个思路,设计一个 Level 类型的枚举:

class Employee {
      private String name;
      /**
       * 薪水
       */
      private int salary;
      /**
       * 工龄
       */
      private int workAge;
      /**
       * 职级
       */
      private Level level;
  }

  enum Level {
      P6, P7;
  }

假设哪天悲催的打工人毕业了,需要计算赔偿金,简单算法赔偿金=工资*工龄

   class EmployeeService {
        public int calculateIndemnity(int employeeId) {
            Employee employee=getEmployeeById(employeeId);
            return employee.workAge * employee.salary;
        }
   }

后来,随着这块业务逻辑的演进,其实公司是家具备人文关怀的好公司,再原有基础上,按照职级再额外补发一定的金额:

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 是用来解决「大泥球」代码的利器。
一种好的实现方式是枚举升级为枚举类,通过设计「值对象」来重新建模员工等级:

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:

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 是一致的算法。
当然,并不是强求你把所有的枚举都替换成类模型来定义,这不是绝对的。还是要按照具体的业务逻辑来处理。