设计模式 – 单一责任原则是否适用于职能？

发布时间：2020-12-13 20:47:27 所属栏目：百科来源：网络整理

导读：根据Robert C. Martin的说法,SRP表示： There should never be more than one reason for a class to change. 但是,在他的书“清洁代码”第3章：函数中,他展示了以下代码块： public Money calculatePay(Employee e) throws InvalidEmployeeType { switch (e

根据Robert C. Martin的说法,SRP表示：

There should never be more than one reason for a class to change.

但是,在他的书“清洁代码”第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);
        }
    }

然后陈述：

There are several problems with this function. First,it’s large,and when new employee types are added,it will grow. Second,it very clearly does more than one thing. Third,it violates the Single Responsibility Principle (SRP) because there is more than one reason for it to change. [emphasis mine]

首先,我认为SRP是为类定义的,但事实证明它也适用于函数.其次,这个功能有多个原因需要改变？我只能看到它因员工的变化而发生变化.

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

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等.所有这些类和方法都有这样的代码.改变会很容易吗？

附：一旦你看到if-else或case语句很长,你就可以开始考虑SRP了.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!