How does this example from Robert Martin's book violate the Single Responsibility Principle? [duplicate]

Question

According to the book "Clean Code" on page 38, the following lines of code violate the single responsibility principle. However, I cannot understand how there are "multiple" reasons for it to change?

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);
    }
}

It seems to me that the purpose of this class is singular: to calculate the pay of commissioned, hourly, or salaried employees--and these three functions are at the same level of abstraction and one level below the top-most CalculatePay(). Is he referring to the fact that more employee types might be added?

Answer 1

There are five concerns here:

• Determine which type of pay to calculate.
• Calculate commissioned pay.
• Calculate hourly pay.
• Calculate salaried pay.
• Validate the employee type.

What might compel us to modify the class containing this method?

• Perhaps we add a new type of employee. Now we need to add new calculation logic.
• Perhaps we modify an existing type of employee. Now we need to modify an existing employee type's logic.

Multiple types of employees have their calculations in the same class. Each type of employee is a reason for this class to change. Hence, it violates the Single Responsibility Principle.

Moving each pay type to its own class (think: Strategy pattern) would localize the reasons to change to one class per employee type, giving each one reason to change.

Finally, using dynamic dispatch to select the pay calculation further separates the concerns by offloading the selection and validation logic itself to the compiler.