java - Understanding the Single Responsibility Principle

Question

I am quite confused on how to determine if a single method has one responsibility being done just like the following code from the book Clean Code

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

As the author stated on this code snippet: "...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.". On a first glance at the code I was thinking that how come that the method violates SRP since if there is a change in the code it would be the switch statement only if there will be an added employee type but as I try to understand the method further I came up with a hypothesis on why it violates the said principle.

My hypothesis is that since the name of the method is calculatePay(Employee e) then the only responsibility of this method is for the payment computation as the method's name suggest but since inside the method there is a switch on filtering the type of Employee this filtering is now a different or another responsibility thus violates SRP. I don't know if I got it right.

Answer 1

"...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."

There lies your answer. Every time a new Employee.Type is added that method will have to change. Also, the calculation for each Employee.Type might change too.

A better solution would be to create an Abstract Factory for Employee and each derivative of Employee having it's own implementation of CalculatePay. This way, only ONE class needs to changed when the Calculation changes or when a new Employee.Type is added.

Here is another extract from Clean Code that explains in more detail -

The solution to this problem (see Listing 3-5) is to bury the switch statement in the basement of an ABSTRACT FACTORY,9 and never let anyone see it. The factory will use the switch statement to create appropriate instances of the derivatives of Employee, and the various functions, such as calculatePay, isPayday, and deliverPay, will be dispatched polymorphically through the Employee interface. My general rule for switch statements is that they can be tolerated if they appear only once, are used to create polymorphic objects