Single Responsibility Principle Explained - SOLID Design Principles | Example Code |  InterviewDOT
Channel: Interview DOT
Date: 2020-03-22

Click here - https://www.youtube.com/channel/UCd0U_xlQxdZynq09knDszXA?sub_confirmation=1 to get notifications.

Tamil Single Responsibility Principle Explained - SOLID Design Principles | InterviewDOT

The single responsibility principle (SRP) states that every class or module in a program should have responsibility for just a single piece of that program's functionality. Further, the elements of that responsibility should be encapsulated by the responsible class rather than spread out in unrelated classes.

The Single Responsibility Principle is the key software engineering principle which determines how we should modularise code in object oriented programming. Formulated by Robert Martin and hammered home relentlessly by him over the years, the power of the principle and his efforts in promulgating it as the S of the SOLID group of principles have resulted in this being something that anyone who claims to know anything about software engineering will be familiar with.

The Benefits
The class is easier to understand
When the class only does "one thing", its interface usually has a small number of methods that are fairly self explanatory. It should also have a small number of member variables (less than seven-ish).

The class is easier to maintain
Changes are isolated, reducing the chance of breaking other unrelated areas of the software. As programming errors are inversely proportional to complexity, being easier to understand makes the code less prone to bugs.

The class is more reusable
If a class has multiple responsibilities, and only one of those is needed in another area of the software, then the other unnecessary responsibilities hinder reusability. Having a single responsibility means the class should be reusable without modification.

The Single Responsibility Principle (SRP): A class should have one, and only one, reason to change.

The SRP is roughly the same as having "high cohesion". A class is said to have high cohesion if it's behaviours are highly related, and strongly focused. The SRP states that a class should be cohesive to the point that it has a single responsibility, where a responsibility is defined as "a reason for change."

Frequency and Effects of Changes
We all know that requirements change over time. Each of them also changes the responsibility of at least one class. The more responsibilities your class has, the more often you need to change it. If your class implements multiple responsibilities, they are no longer independent of each other.

You need to change your class as soon as one of its responsibilities changes. That is obviously more often than you would need to change it if it had only one responsibility.

That might not seem like a big deal, but it also affects all classes or components that depend on the changed class. Depending on your change, you might need to update the dependencies or recompile the dependent classes even though they are not directly affected by your change. They only use one of the other responsibilities implemented by your class, but you need to update them anyway.

In the end, you need to change your class more often, and each change is more complicated, has more side-effects, and requires a lot more work than it should have. So, it's better to avoid these problems by making sure that each class has only one responsibility.