[What does the letter “S” in S.O.L.I.D stand for?] — The Duty of the Developer As A Professional #6
Hi Re-Programmerz!
In the continuity of our series The Duty of The Developer as a Professional and as promised in our previous article The Golden Rule to choose a good Architecture, we will see in details the five S.O.L.I.D principles, starting with the first letter: S for Single Responsability Principle (SRP).
Let’s play a small game!
Before beginning to read our article, I would like you to write on a paper your definition of Single Responsability Principle, then put this piece of paper, face down, in front of you. Do not read it again until the end of the article. Of course, you can write something like “I don’t f***ing know” or even leave the page blank — no problem at all :)
We will come back later on what you have written.
Happy reading!
Definition
“A module should have one, and only one, reason to change.”
“A module should be responsible to one, and only one, role/actor.”
— Robert Martin
Role/actor?
First of all, in our opinion, this principle, due to its name "Single Responsability", has often been misunderstood and leads to a lot of confusion and ambiguity.
In fact, we link Single Responsability directly and immediately to Single Task, which makes us think that SRP is defined the following way:
"A function/method should do no more than one thing — one task."
This definition more likely corresponds to Clean Code's principles (e.g : a function/method should be no longer than 25 lines of code, a line of code should not exceed 100 characters, etc…), and not to Single Responsability.
A role/actor is a specific group of people (one or many) that may require a specific kind of changes to the module. A role/actor holds a responsibility.
"A responsibility is a series of functions that serve a role/actor."
— Robert C. Martin, aka Uncle Bob
How to apply SRP on any feature? What does it offer?
Let’s see an example of a feature X that we need to develop. We’ll separate our code into 4 main classes:
- View, which represents the design of our feature.
- Presentation, which handles the formatting and the styling of the content (i18n/l10n, color, font family, text size, etc…).
- Business Logic, which implements all the business rules related to the feature.
- Networking, which is in charge of all calls to different web-services.
Of course, there are other layers/classes contributing to the feature (like Navigation, Database, etc…). We make it simple not to mention these in this example but focus on the 4 important parts above.
As we all know, a team is, in general, made of the following roles:
- Developer (ourselves), who assures the technical conception and the implementation of the feature by producing functional code and unit tests.
- Designer, who is responsible for the User Interface (UI). He/she delivers mock-ups and prototypes.
- Content Strategist, who is in charge of the content and its presentation. He translates the textual content into different languages while making sure that it is legit and conforms to Accessibility rules (definition: access to communication services for people with reduced mobility).
- Product Owner, who defines the feature by providing related business rules.
- Back-end team, who gives API contract, including request and response interfaces. Clients of their APIs can be either mobile applications, websites, or another server, etc…
According to you, to which role/actor can we associate the View class? We all agree, (don’t we?) that the response is: the Designer! Doing the same for the rest of the classes, we would have this mapping:
Thanks to SRP, we can associate each one of our classes to a team member. We can now know where to put our code (in which class, for which responsability) to ensure the proper functioning of our feature!
…only one reason to change?
Now that each class corresponds to an only and unique responsability - an only and unique role/actor, the only moments that we would have to change or modify it, would be to satify a new request of the associated role/actor.
In fact:
- If the Designer wants to change the position of an image or a text, we will update the View class.
- If the Product Owner, wants to change a Business rule, we will update the corresponding class: Business Logic (named Interactor in Clean Architecture, we will talk more about that in another article 💪)
- Etc…
Not respecting the SRP is dangerous!
Let’s assume that a class Foo does not respect the SRP: it contains both Business and Networking code.
If the Back-end team changes a node in the JSON response needed for our feature, we will have to modify Foo code.
The danger here is to break unknowingly the Business rules of the Product Owner presenting in the same class Foo, while trying to response to Back-end team’s changes. The Product Owner would not be happy seeing that a change coming from another role/actor affects his Business rules, whereas he has not asked for any change.
Conclusion
The Single Responsibility Principle (SRP) allows us to organize our code well correspondingly to the appropriate roles/actors and not to mix responsibilities within a single class.
The reason to change a class will only be through the actor who requests that change.
We are reaching the end of our article. You can now use the definition that you wrote down some minutes ago, if you have joined the game :) Do you think yours is correct?
You know what, if you have understood this principle, you have just taken a first big step in learning the well-known Clean Architecture! A dedicated article will be made to explain it more once we have finished going around the remaining principles of S.O.L.I.D.
Next article: the second letter from S.O.L.I.D - O for Open-Close Principle!
We hope that you acquired something useful today with this post! Give us claps if you liked it and do not hesitate to share it as much as you can! 🔥
This article is co-written with Abderrahim Benmakhlouf and Mohammed HIMOUD.