Shulou(Shulou.com)06/02 Report--

This article mainly introduces the object-oriented design principles of SRP example analysis, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor with you to understand.

As a developer, I believe you have heard such a saying: "the more single the responsibility of a class, the easier it is to reuse." How do you understand that? Let me give you an example, the check code. Suppose you get a task now that is to implement the check code function of the login module in our system. What do you do? I think most of our developers will do the following designs (of course, worse, someone will simply write a utility class that provides a static generateVerifyCode method):

What's wrong with this design? It seems reasonable enough to have an interface and an implementation. We looked at what actually happened to see if it was reasonable enough-when our system was first launched, the implementation of the check code was not as gaudy as it is now, and at that time it was just a white background and a set of undistorted numbers; but then the demand evolved, because the original check code may be deciphered, so we need to distort the numbers, and we can not only produce numbers, but also letters to make it more difficult to decipher. What are we going to do then? Based on the above design, you need to modify the VerifyCodeGeneratorImpl class (note: even in this unreasonable design, it is not good to modify the implementation, it is better to discard this implementation and add an implementation), modify the code that generates random numbers, and add distortion processing logic to the random text generated when the picture is generated. Modify the code due to changes in requirements, which shows that the original design is not good and violates another principle of object-oriented design, the "OCP principle". In addition, this principle mainly means that a class (or module) can only be extended, but not modified.

A closer analysis shows that the reason why the implementation class needs to be modified is that it takes on two separate responsibilities-generating random text and generating check code images. Okay, let's try to separate the responsibility for generating random text, designed as follows:

Under this design, the responsibility of generating random text of check code is separated into a separate evolution system, and new implementations such as generating random text of Chinese characters can be added with the change of demand, and the display of check code is not affected. But this design has not yet met the requirements of the change, because the current demand is not only random text content from pure numbers to numbers plus letters, but also requires display when the number is distorted, in this design, we can add a new VerifyCodeGenerator implementation such as TransformedVerifyCodeGeneratorImpl to replace the original VerifyCodeGeneratorImpl. This is possible, but there are better designs, as follows:

In this way, the image generation responsibility is abstracted into an evolutionary system separately, so that if you need to add background color or background noise to display the check code in the future, you only need to add a new ImageGenerator implementation. And ImageGenerator, as a general class, can be reused by other classes with corresponding requirements for generating pictures, rather than being limited to generating check codes. With the dependency injection of Spring, we can generate Numer M kinds of check codes (N is the number of implementation classes of RandomTextGenerator and M is the number of implementation classes of ImageGenerator). Based on the initial design, we need to create VerifyCodeGenerator implementation classes with low reusability.

It can be concluded from the discussion of the above example that the more responsibilities a class (or as big as a module, as small as a method) takes on, the less likely it is to be reused. This is what the single responsibility principle (SRP) is all about: as far as a class is concerned, there should be only one reason for its change.

With this principle in mind, let's look at a common DAO design:

Interface DAO {Connection connect (); void close (); void executeUpdate (); ResultSet executeQuery (String sql);}

Is there anything wrong with this interface? it seems that a lot of people do it. Just imagine that if the underlying database changes, the code of the connect method may need to change (some people say we don't need to change because we use the DataSource abstraction provided by Spring to isolate changes in getting database links). This interface contains two responsibilities: database link management and data manipulation.

In practice, how to identify responsibilities is easier said than done. For example, some people may say that "generating a check code picture" is an independent responsibility. I say yes. If our check code picture stays the same, the original design is not very bad, but just lost a little reusability (for example, the logic of generating random text may be reused by other modules). But the demand changed later, not only numbers, but also letters, which shows that the generation of random text is a changing latitude, and there are likely to be new changes in the future, so this responsibility should be made independent. The demand also says that the displayed text needs to be distorted, which shows that the generation of the picture is also a changing latitude, along which there are likely to be new changes in the future, so this responsibility should be made independent. The latitude of change affected by a change in demand is often a responsibility that should be independent. So if you receive a requirement and find that you need to modify an existing class, consider whether the original design is unreasonable and does not separate the responsibilities that should be separate. Changes in requirements, combined with experience and common sense, can slowly identify what granularity responsibilities should be assigned.

The principle of single responsibility is meaningful not only for class design, but also for architecture design based on modules and subsystems, and there should be only one reason for its change in a module or subsystem. the difference is that the granularity of responsibility undertaken by modules and subsystems is another level compared with classes.

If I were to list the qualities that a good design should have, I would say: high cohesion, low coupling. The principle of single responsibility is a principle that needs to be followed to achieve high cohesion and low coupling.

Thank you for reading this article carefully. I hope the article "sample Analysis of SRP in object-oriented Design principles" shared by the editor will be helpful to you. At the same time, I also hope that you will support and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.