Software design principles and patterns-single accusation Principle

For a class, there should be only one reason for its change. It is very simple. If a class assumes the extra responsibilities, there will be multiple reasons for its change. This means that these responsibilities are coupled together. Of course, a change in responsibility may weaken or suppress this class's ability to complete other duties. The final result is that this coupling will lead to a fragile design. Example: The Retangle class has two methods. One method draws the rectangle on the form, and the other method calculates the area of the rectangle:

Additional responsibilities
There are two different programs that use the Rectangle class. One is the calculation of the geometric aspect. In this case, the Rectangle class will help the sub-geometric program, and it will never draw a Rectangle in the window. Another program is related to graphics. It may also perform geometric calculations, but it will certainly draw rectangles in the window.
Therefore, this design violates the single responsibility principle, that is, the rectangle class has two responsibilities: 1: providing a mathematical model of the rectangular ry; 2: draws a graphical user interface of a rectangle. Such a design may lead to a change in a place that will lead to a change in a column in another place. A better design is to separate the two responsibilities into two completely different classes. As follows:

What is duty?
It can be understood as the cause of change. If you can think of changing a class with one motive, this class has more than one responsibility. Sometimes it is difficult for us to do this. We are all used to taking responsibilities into account in group mode. The following interface looks reasonable: The four functions declared by this interface are indeed the functions of the modem:

Interface Modem
{
Void dial (string pno );
Void hangUp ();
Void send (string c );
Void recv ();
}

However, this interface shows two responsibilities. The first is connection management [dial; hangUp], and the second is Data Communication [send; recv]. the question is, should these two roles be separated? This depends on the way the application changes. If the program changes will affect the signature of the connection function, the design will be rigid. Because the send; recv class must be re-compiled. The number of deployments often exceeds the expected number. In this case, you need to separate the two responsibilities. But on the other hand, if the way the Application Changes always leads to the simultaneous change of the two roles, you don't have to separate them.
Conclusion: A single responsibility is one of the simplest and most difficult to use in all principles. We will naturally combine our responsibilities. Much of what software design really needs to do is to discover responsibilities and separate them.