Several weeks ago, we briefly discussed the SOLID design principles in CS-343. This discussion was supposed to lead into a homework assignment where we would research a couple of principles, but since this never happened I decided to research a SOLID principle for a blog post instead. In this post, I will be focusing on the Single Responsibility Principle, or SRP (the ‘S’ in SOLID). This principle declares that a class should have only one reason to change, or in other words, a single responsibility. It sounds like a simple concept, but actually implementing it can be challenging. My research into the SRP helped me come across a blog post by Patrick Smacchia titled “SOLID Design: The Single Responsibility Principle (SRP),” which defines guidelines that may help make the principle easier to follow.
The blog can be found here:
In the blog, Smacchia explains that the SRP is not as simple to follow as it sounds, because different programmers may define a responsibility or a reason to change in different ways. For this reason, he approaches the principle based on its fundamental purpose of determining which logic should be in which class. From this approach, he explains several aspects of the SRP using example code, and he provides a set of concrete guidelines that can help enforce the principle. I chose to share this post because Smacchia’s approach to explaining the SRP has helped me understand it better by getting me to think about it from a more fundamental perspective. I also think his guidelines would be useful to any programmers, myself included, who intend on following this principle in their projects.
I certainly intend on referring back to the guidelines included in this blog to ensure that my future projects follow the SRP. Although there are a couple I don’t fully understand, such as the one on POCO classes, I think the others will greatly help me adhere to the SRP. His suggestion to keep logic related to different functions separated into different classes makes sense thanks to his Employee example, which I will refer back to when deciding which functions should be separated into different classes. I found Smaccia’s discussion on cohesion especially interesting because it exposed me to the Lack of Cohesion Of Methods metric, or LCOM, which is used to actually quantify how cohesive a class is. It surprised me that a more complex class can have a lower LCOM score than a simpler one, and that a class’ simplicity does not represent its adherence to the SRP. I will definitely refer back to this blog to help me ensure that my own classes keep a low LCOM score even as they grown more complex as a way to follow the SRP. I have certainly had issues with classes getting too large and doing too many things in the past, and I think learning more about the SRP from this blog will help me avoid this problem in the future.