Single Responsibility Principle (SRP)-Single Responsibility Principle for OO design

Preface

Robert C. martin summarizes the Principles that should be followed in Object-Oriented Design (OOD). These Principles are called "prinles les of OOD ", for more information about Principles of OOD, see Object Menter.

This article introduces the Single Responsibility Principle in "Principles of OOD": Single Responsibility Principle (SRP ).

You can view the original Single Responsibility Principle (SRP) from here.

Summary

There shoshould never be more than one reason for a class to change.
Never let a class have multiple reasons for change.
In other words, if a class needs to be changed, there will always be only one reason to change it. If there are multiple reasons to change it, you need to redesign the class.

The core meaning of the SRP (Single Responsibility Principle) Principle is that only one class has only one Responsibility. This is also the naming meaning of a single responsibility principle.

Why can't a class have more than one responsibility?
If a class has more than one responsibility, there will be multiple reasons for this change, and this change will affect users with different responsibilities (different users ):
1. On the one hand, if an external class library is used by a role, the user using another role has to include this unused external class library.
2. On the other hand, if a user needs to modify one of his/her roles for some reason, the user of another role will also be affected and he/she will have to re-compile and configure it.
This violates the design's open and closed principles and is not what we expect.

Division of duties

Since a class cannot have multiple responsibilities, how can we divide them?
Robert C Martin gave a famous definition: One of the responsibilities of a class is one of the reasons for this change.
If you can think of more than one motive for changing a class, then that class has more than one responsibility.
If you can think of multiple reasons for changing a class, this class has multiple responsibilities.

In the original article Single Responsibility Principle (SRP), a Modem example is provided to illustrate how to divide duties. Here we also use this example to illustrate:

SRP violation example:
Modem. java
Interface Modem {
Public void dial (String pno); // dial
Public void hangup (); // hang up
Public void send (char c); // send data
Public char recv (); // receives data
}
At first glance, this is an interface design without any problems. But in fact, this interface contains two responsibilities: the first is connection management (dial, hangup), and the other is Data Communication (send, recv ). In many cases, these two roles have no common responsibilities. They are changed for different reasons and called by different programs.
Therefore, it violates the SRP principle.

The following class diagram divides two different responsibilities into two different interfaces, so that at least client applications can use interfaces with a single responsibility:

Let ModemImplementation implement these two interfaces. We have noticed that ModemImplementation combines two responsibilities, which are not what we want, but are sometimes necessary. Generally, for some reason, we have to bind multiple roles to a class, but at least we can separate the concepts that the application cares about by splitting interfaces.
In fact, a better design for this example should be like this,

Summary

Single Responsibility Principle (SRP) establishes a benchmark for determining the abstract granularity of classes (interfaces) from the perspective of Responsibility (changing reasons): In designing classes (interfaces) for the System) to ensure their single responsibility.