Single Responsibility

The Single Responsibility Principle (SRP) states that a class or module should have one,

and only one, reason to change. This principle gives us both a definition of responsibility,

and a guidelines for class size. Classes should have one responsibility—one reason to

change.

What is a Responsibility?

In the context of the Single Responsibility Principle (SRP) we define a responsibility to be “a reason for change.” If you can think of more than one motive for changing a class, then that class has more than one responsibility.

So how do we start?

Each complex problem cannot easily be solved as a whole. It is much easier to first divide the problem in smaller sub-problems. Each sub-problem has reduced complexity compared to the overall problem and can then be tackled separately. There is a proverb whose origin is from the Romans which says: "Divide et imperat", translated to English this means: "Divide and reign".

We want our systems to be composed of many small classes, not a few large ones. Each small class encapsulates a single responsibility, has a single reason to change, and collaborates with a few others to achieve the desired system behaviors.

Take few steps towards SRP, think before ink -

• The name of a class should describe what responsibilities it fulfills.

• If we cannot derive a concise name for a class, then it’s likely too large.

• The more ambiguous the class name, the more likely it has too many responsibilities.

• We should also be able to write a brief description of the class without using the words “if,” “and,” “or,” or “but.”

For example: Class "A" downloads the files and unzips them. This is clearly violation of SRP because this class is handling 2 responsibilities. One is to download the files and followed by unzipping them.

Why is it important to separate the responsibilities into separate classes?

Each responsibility is an axis of change. When the requirements change, that change will be manifest through a change in responsibility among the classes. If a class assumes more than one responsibility, then there will be more than one reason for it to change.

If a class has more than one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

So, Yes. SRP is important. It is one of the powerful principal which helps us develop code which is -

• more readable, that is easier to understand

• less error prone

• more robust

• better testable

• better maintainable and extendable

• maximizes the cohesion of classes.

The SRP is one of the simplest of the principles, and one of the hardest to get right. Conjoining responsibilities is something that we do naturally. Finding and separating those responsibilities from one another is much of what software design is really about.