Understanding the principle of shared responsibility

I am very confused about how to determine that one method has one responsibility, performed in the same way as the following code from the Clean Code book

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 in this code fragment: "... obviously does more than one. Thirdly, it violates the principle of single responsibility (PSA), since there is more than one reason for changing it. " At first glance in the code, I thought that it turned out that the method violates SRP, because if there is a change in the code, it will be a switch statement only if there is an added employee type, but as I try to understand this method, I came up with a hypothesis about why it violates this principle.

My hypothesis is that since the method name is calculatePay(Employee e) , the only responsibility of this method is to calculate payments, as the name of the method is suggested, but since there is a switch inside the method for filtering type Employee this now filtering is different or another responsibility violates SRP I do not know if I understood correctly.

+6
source share
2 answers

"... 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. Each time a new Employee.Type added, this method will need to change. In addition, the calculation for each Employee.Type may also change.

A better solution would be to create a Factory Summary for Employee and each derivative of Employee that has its own implementation of CalculatePay . Thus, only when changing Calculation or when adding a new Employee.Type only one class should be changed.

Here is another example from Clean Code that is explained in more detail -

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

+5
source

I usually use class level SRP. This prevents classes that are too large and take up too many roles.

I view “responsibilities” as conceptual. Therefore, I would say that your method has only one responsibility: calculate wages.

I try to follow Google’s recommendations and look for these warning signs that suggest that you are wandering from SRP:

  • To summarize that the class includes the word "and."
  • The class will be difficult for new team members or inexperienced developers to read and quickly get.
  • The class has fields that are used only in some methods.
  • The class has static methods that work only with parameters.

In another note, however, your code contains a switch statement, which suggests that you might wander off OCP ...

+3
source

All Articles