Understanding SOLID: Single Responsibility Principle

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