Rebuilding serialization in big talk 18: The most common problem

Although the extraction method is simple, it is not so easy to operate. The greatest difficulty in completing the extraction method is how to exchange data between the extraction function and the original function. Just like pulling a big tree out of the soil, the root of the root is the root of the root. Before the code is extracted, it is in the same function as other programs. Therefore, each code segment can interact with each other without scruples. However, when we extract code from the original function, the extracted code forms a wall with the code in the original function. The data to be exchanged can only be interacted with the return value through parameters, this will cause us a lot of trouble.

Extract the code from the original function and put it into the new function. First, many errors are displayed, that is, many variables are undefined, this provides a clue for us to analyze the variables that require interaction. Writing all the data to be interacted to the function parameters is theoretically correct, but not a good design. On the one hand, it looks very ugly and has a long list of parameters, making the program silly and difficult to understand; on the other hand, it also leaves a hidden risk: when the program changes, it is very likely that the function interface is changed because of adding parameters, which we do not want to see and try to avoid. Therefore, in terms of data interaction, I prefer to use value objects. A value object is a simple object that has no business and is only used to transmit data. It is not impossible to insert a bunch of variables into a value object in disorder. In fact, we often do this in the early stages of restructuring. However, with the deepening of refactoring, value objects are gradually optimized. In the end, each value object should correspond to a thing in the real business, and the variables it contains, it is the property that this thing should possess. Therefore, the parameters passed by the final function should be several value objects, and several variables other than these value objects. We recommend that you set no more than six parameters for a function, preferably 1 ~ Four.

Another troublesome problem is the return value. In the Java World, function return values can only be one. What if our program needs to return two or more results? It is a good way to return a value object. However, in a function, the passed parameter is a value object, and the returned value is another value object. If you design it like this, a large number of value objects will occur, resulting in a flood of value objects. The data to be returned is directly inserted into the parameter value object, which is another good method we can use. In Java, there is no difference between the actual parameters of the form parameter. If an object is passed in, a certain attribute of the object is modified in the function, this modification still takes effect even if the program jumps out of the extraction function and returns to the original function. By accessing the object through the original function, the function of extracting the return value of the function is implemented substantially. From another perspective, our function is the process of processing data in these value objects. This process is like a motorcycle production line. For this motorcycle, you first have an engine installed and I have two wheels installed. Our processing process is designed to process a value object in sequence by a series of functions. In this way, the value object becomes a carrier that interacts data between the original function and the extraction function. In this way, the problem of parameters and return values discussed above will be solved.

For example, our system now submits a form from the front end. First, we use servlet or action to obtain the data passed by the front end and fill in a value object. Then the form may require a series of validation, So we pass this value object to each validation function. The validation function performs some validation on the value object, and may also write some flags on the value object. Then, some processing functions may be called to query some data from the database and fill it in the value object. After a series of validation and processing, the data in the value object is filled completely, and finally handed over to the persistence function to write the database. To call all these functions, you only need to pass the value object, or even have no return value. The problem is solved.

In addition, another problem that always leads us to think over and over again in the Practical Extraction method is the problem of "Drawing the Red Line. As mentioned above, block operations in the original function, such as condition statements, loop statements, and try statements, are all obvious signs of extraction operations. But the key issue is that this does not mean that all the code in the block operation is the scope of the extraction function. We need to consider many factors. Of course, the most intuitive idea was to extract all the code from block operations. However, when we add a function to analyze its parameter list and return values, we may find problems. Some parameters, such as request and response, are not directly transmitted as parameters. At this time, it is a more intuitive idea to remove the first or last part of the extracted function from the function and put it back into the original function. In addition, when some functions have similar functions and parallel positions, we may merge them in the future. Therefore, when functions are extracted, you may want to draw lines in the same position. The above problems are all issues that need to be carefully considered during the reconstruction process.

Finally, we will discuss the naming of the extraction method. In the past, the naming of methods was often a bit confusing. The reason is that programmers are too casual about this aspect, and the reason is that we are not standing for it. We should name it from the perspective of users rather than developers. We should tell the user what function will be executed when this method is called, that is, what its operation intention is. In this way, the user can correctly understand and use it properly. The getblsj () in the response is the best proof (see the 5.1 super big function): the first name is getblsj () because it gets the processing time from the developer's point of view, in this case, other users can only use it to obtain the processing time. But what is its true intention? Is the conversion date format, so it is renamed as transformdate (). Because of this renaming, other developers can use it to convert other similar dates, not just the processing time. This shows that the naming of methods is so important that we have to check.

In addition, I suggest you not to be too professional. For some professional terms, look up the dictionary to find an English word that you don't even know. How can you ask your readers to know it! The purpose of naming is to increase readability. Therefore, professional English words do not help improve readability and should be avoided as much as possible. However, some conventional pinyin words cannot be used. For example, the taxpayer identification number is named taxpayerid or taxpayercode. However, if the whole industry uses nssbh, you can understand it, but the taxpayerid or taxpayercode is abrupt. Another example is the invoice. Someone looks up the dictionary and name it invoice. Invoice can be an invoice or a variety of other documents related to the commodity list. Therefore, it is not as simple and clear as naming FP.

Big talk rebuilding serialization home: http://www.cnblogs.com/mooodo/p/talkAboutRefactoringHome.html

Note: I hope that the author or source should be noted to show my respect for the author when I reprint this article. Thank you!

Rebuilding serialization in big talk 18: The most common problem