I get it. You wanna get a job at google but your dumb ass don't know SOLID.
Don't worry, Uncle T is here to help
WHAT THE HELL IS SOLID?
Well my friend SOLID is simply an acronym for
- S - Single Responsibility Principle
- O - Open Close Principle
- L - Liskov Substitution Principle
- I - Interface Separation Principle
- D - Dependency Inversion
Now I know this may seem a bit intimidating for you, but don't worry we will take it step by step starting with the single responsibility principle or its shorthand SRP.
WHAT THE HELL IS SRP?
As Robert Martin aka Uncle Bob explains it:
Single responsibility principle states that a class should only have one reason to change, in other words like it should do only one thing.
okay.
calm down.
I know your bored and confused but stay with me here.
What he basically means is that a class should only have one responsibility.
Now your gonna ask: "Uncle T, what's a responsibility?"
WHAT THE HELL DO YOU MEAN BY RESPONSIBILTY?
To explain this, I will blatantly copy the example that Uncle Bob wrote in this post.
Imagine you have a company, let's call it Uncle T Burgers.
The management of Uncle T Burgers would look something like this:
- CEO (Chief Executive Officer) makes sure that the company is alive.
- CFO (Chief Financial Officer) handles the financial issues.
- CTO (Chief Technical Officer) handles the the technical side of things.
- COO (Chief Operating Officer) handles and manages the day to day tasks.
And then we have a lowly class called Employee that looks something like this:
public class Employee {
public Money calculatePay();
public void save();
public String reportHours();
}
I'm gonna ask you this question, "who is responsible for this class?"
You might say the programmer.
Your wrong.
The programmer is responsible for translating business logic into code, bug fixing, and refactoring.
But who manages the logic?
Multiple people in different fields of the company, for example the:
The CFO will manage the financial logic (employees salary, profits, losses, etc..)
The CTO will manage the technical logic ( tech stack, practices, etc..)
The COO will manage the operational logic (work hours, office management, etc..)
Now we can go back to the question "Who owns this class?"
The answer as it currently is 3 people.
How?
Well let's break down the code:
Let's say the calculatePay function breaks down logically and accidentally pays the employees double what they are supposed to take.
Who is responsible from the three C-Level executives.
You would say obliviously the CFO.
How about the save method, which is responsible for saving employees info to the database, let's say it breaks down and starts deleting records.
Who is responsible?
Your right if you said the CTO.
Last but not least the reportHours method, which simply gets the number of hours the employee has worked and gives back a report. Let's once again imagine that the reports get skewed and you get back incorrect hours.
Who is responsible?
Yes, it's the COO.
So the ideal case scenario would be that one class should be owned by only one entity.
A revamped employee example would look like this:
public class Employee {
public void save();
}
public class EmployeeFinances {
public Money calculatePay();
}
public class EmployeeOperations {
public String reportHours();
}
Now every class is owned exactly by one entity.
WHY WOULD I WANT TO DO THIS?
That's a good question but the answer is pretty simple, your code will be a mess without it, imagine putting all your code in one file, yea its a mess, but if you want more concrete reasons I got you covered.
Easier Software
Once you follow SRP it makes your code easier to implement and prevents unexpected side-effects of future changes.
Requirements
Business requirements change all the time, if your class has too many responsibilities, then these responsibilities become co-dependent of each other.
Brings joy to people
Once classes have a single responsibility they simply become much easier to work with, you can easily explain to your colleagues what the class does, and bug fixing becomes a lot easier.
FINAL THOUGHTS
I personally think the best way to end this is by a quote that Robert Martin wrote:
However, as you think about this principle, remember that the reasons for change are people. It is people who request changes. And you don’t want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons.
PS. This was my first post, and I would appreciate your criticism
Top comments (10)
I saw too many developers (myself included) writing classes with one method each because of the SRP. That's not great. On top of that, in practice you'll have no clue who's is responsible for what in a company, and in a startup the CTO can do many, many things, for example. What do you do in that case? Create a god class?
It's more important for me to understand why the SRP was created and by what it was inspired. If you want another view on the SRP, I wrote about it here: thevaluable.dev/single-responsibil...
Hi, really appreciate the feedback. What your saying is indeed correct, and SRP is merely a principle that shouldn't be always followed 100% to the brim.
What a great article that was Matthieu. Thank you very much!
ps: Robert Martin is really charismatic :D
Glad you liked it! Robert Martin is more and more controversial in the industry: some hate him, some love him. Personally, I just think his opinion is often way too absolute.
Creating a class with just a single method is totally fine for me.
Overengeenering is another talk.
First of all I really liked your post and the example that you've provided.
Secondly I would like to comment on the "WHY WOULD I WANT TO DO THIS?" section. I get the feeling as I read it that whenever I implement SOLID or SRP I will always have an improvement on the code, which I don't believe is true since it get's more complicated.
As Matthieu said for example, can you imagine creating all classes with only one method? That's practically insane isn't it?
I would like to think about it like this: we don't go looking for cases to implement SOLID or SRP or any other pattern until we come to the case that we need it.
Oh deer.. Probably, you have never had to deal with maintaining huge legacy monoliths.
It is generally a good idea to follow best practices from the start. As the project grows, technical debt will start getting accumulated really fast.
It's true I've never delt with huge legacy monoliths mainenance and following best practises from the start (and along the way) sounds logical to me. All I am asking: is implementing SOLID or SRP always a best practise? Aren't there cases that introduces needless complexity and overdesign (as Robert Martin states)?
It is good to learn good practices early on.
What is really bad is premature optimization :D
You are great at conveying things literally.