[Agile design] 2. SRC single Responsibility Principle

I. Definition

　　A class should have only one reason for change.

Ii. Why SRC?

Because every responsibility is an axis of change. When the demand changes, this change will reflect the changes in class responsibilities. If a class assumes more than one responsibility, there are multiple reasons for its change.

If a class has too many responsibilities, these responsibilities are coupled. Changes in one role may weaken or inhibit this class's ability to complete other duties. This coupling will lead to a fragile design. When a change occurs, the design will be unexpectedly damaged.

Iii. Case Study

Consider the design in the diagram.

　　

The rectangle class has two methods: one is to draw a rectangle to the screen, and the other is to calculate the area of the rectangle. Currently, two applications use the rectangle class. One is to use rectangle to calculate the area of a rectangle, but it does not need to be drawn. The other application may draw a rectangle or calculate the area.

This design violates the single responsibility principle. The rectangle class has two responsibilities. The first responsibility provides the calculation of the rectangle area, and the second responsibility provides the rectangle painting. SRC violations cause some serious problems.

There are the following problems with this SRC program:

First, we must include the GUI code in the program on the left, even if we do not need it.

Second, if the changes to the right side of the Program lead to a rectangle change, this change will force us to re-build, test, and deploy the program on the left.

A better design is to separate these two responsibilities into two completely different classes, as shown in. This design moves the calculation part of the rectangle class to the geometricrectangle class. The changes in the rectangle drawing method do not affect the programs on the left.

　　

4. What is duty

　　In SRC, we define responsibility as the cause of change.

If you can think of more than one motive to change a class, this class has more than one responsibility.

Sometimes it is hard for us to notice this, and we are used to taking responsibilities into account in groups. For example, most people think the modem interface below is very reasonable. The four methods declared by this interface are indeed the functions of the modem.

Public interface modem {public void dial (string PNO); // connect public void hangup (); // disconnect public void send (char C ); // send public char Recv (); // receive}

However, this interface shows two responsibilities. The first is connection management, and the second is data communication.

Do these two duties need to be separated?

This depends on how the application changes. If the application changes will affect the signature of the connection management method, this design is rigid because the classes that call send and Recv must be re-compiled and deployed. In this case, the two roles should be separated, as shown in.

　　

 

On the other hand, if the way the Application Changes always leads to the simultaneous change of both roles, you do not have to separate them.

Remember this conclusion,The changed axis is of practical significance only when a change occurs.. If there is no indication, it is unwise to apply SRP or any other principles.

V. Separation and coupling responsibilities

Note that, in, the two roles are coupled into the modemimplementation class. This may not be the best, but it may have to be done. There are often some reasons related to hardware or operating system details, forcing us to couple things that are unwilling to be coupled together. However, for the rest of the application, we have decoupled by separating their interfaces.

6. Persistence

Demonstrate a common violation of SRP.

　　

The employee class includes business rules and persistence control. These two roles should not be combined in most cases. Business Rules often change frequently, but the persistence method does not change so frequently, and the reasons for the changes are completely different. They actually change in two directions, one is changes in the business direction, and the other is changes in the persistent direction.

Binding business rules with the persistence subsystem is a tough task. Test-driven development practices often force us to separate these two responsibilities long before the design stinks. However, if the test does not force this separation, you should refactor the design using the facade, Dao, or proxy modes to separate these two responsibilities.

VII. Conclusion

SRP is one of the simplest and most difficult to use in all principles. We will unconsciously combine our responsibilities. A lot of work really needs to be done in software design is to discover responsibilities and separate those responsibilities from each other.

 

[Agile design] 2. SRC single Responsibility Principle