Single Responsibility Methods31 October 2017
Photo: Kevin Ku - Unsplash
The Single Responsibility Principle is a core element of the SOLID Principles. Wikipedia states that the principle stipulates that
“a class should have only a single responsibility (i.e. changes to only one part of the software’s specification should be able to affect the specification of the class).”
Most developers agree with this approach and structure their code accordingly. Then they create methods in those classes with words like “And” and “Or” in the name. This is a clear code smell that your method is doing too many things. Why structure our classes following SRP and then tool them with confusing methods?
As an example, I have often seen code like
Now I am not interested in showing the actual implementation. What I am showing is that it is common to see a method that does more than one thing. In order for the method to complete it needs to do three discrete steps.
As an aside, by refactoring in this method there is a clear violation of SRP at the class level. FileExists and Download methods should clearly be refactored into a separate class.
This simple refactoring results in two classes that now have a single responsibility. Each method has a single responsibility as well. This improves readability and more importantly makes the methods easier to test. It also makes clear the intent of the methods which reduces the ability for it to cause side effects. Side effects from badly designed methods have lost me countless hours over the years. A final reason to structure your methods in this way relates to reuse. By limiting the methods to a single responsibility you will end up increase reuse significantly as you can chain calls up in various ways that you just can’t when they are grouped together as one method.
To end I will include a quote from Robert C Martin on the subject of SRP
“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”