design-patterns - 单一责任原则是否适用于职能？

根据罗伯特·马丁(Robert C. Martin)的说法，SRP指出:



但是，在他的《清洁代码》第3章:函数中，他显示了以下代码块:

    public Money calculatePay(Employee e) throws InvalidEmployeeType {
        switch (e.type) {
            case COMMISSIONED:
                return calculateCommissionedPay(e);
            case HOURLY:
                return calculateHourlyPay(e);
            case SALARIED:
                return calculateSalariedPay(e);
            default:
                throw new InvalidEmployeeType(e.type);
        }
    }

然后指出:



首先，我认为SRP是为类定义的，但事实证明它也适用于函数。其次，该功能有多个原因需要改变吗？我只能看到它随着Employee的变化而改变。

最佳答案

您可以将上述方法视为属于以下类的对象:

class PaymentCalculator implements Function<Employee, Money> {
  Money apply(Employee) {
    switch (e.type) {
            case COMMISSIONED:
                return calculateCommissionedPay(e);
            case HOURLY:
                return calculateHourlyPay(e);
            case SALARIED:
                return calculateSalariedPay(e);
            default:
                throw new InvalidEmployeeType(e.type);
        }
  }
}

然后，让我们尝试找出修改此类的原因:

员工类型变动薪水

计算逻辑中的更改(新参数作为员工职位，经验等)

对于至少这两种类型的更改，您将不得不使用此方法进行更正。值得一提的是，SRP的目标是实现低耦合和高内聚。要了解这种方法的好处，请尝试假设您有一个包含数百个此类的类和方法的大型系统:calculatePay，calculateVacation，createDepartment等。所有这些类和方法都具有类似的代码。进行更改会容易吗？

P.S.一旦看到长的if-else或case语句，就可以开始考虑SRP。