Refactoring notes-breaking temporary variables

This article is in the study summary, welcome reprint but please specify Source: http://blog.csdn.net/pistolove/article/details/42463871

in the previous article, "Refactoring notes-introduction of explanatory variables" was introduced . This article will introduce the refactoring technique of "break temporary variable".

Let's learn this refactoring technique.

straight to

Discovery: Your program has a temporary variable that is assigned more than once, it is neither a loop variable nor used to collect calculation results.

Workaround: Create an independent, corresponding temporary variable for each assignment.

Double temp = 2 * (_height + _width) before refactoring; SYSTEM.OUT.PRINTLN (temp); temp = _height + _width; SYSTEM.OUT.PRINTLN (temp);

After refactoring final double perimeter = 2 * (_height + _width); SYSTEM.OUT.PRINTLN (perimeter); final double area = _height + _width; System.out.println (area);

Motive

In some cases, temporary variables are used to hold the results of an operation for a lengthy code for later use. This temporary variable should only be assigned once. If it is assigned more than once, it means that they assume more than one responsibility in the function. If a temporary variable assumes multiple responsibilities, it should be replaced (decomposed) into multiple temporary variables, so that each variable assumes only one responsibility. The same temporary variable takes two different things and makes the code reader confused.

Practices(1) in the declaration of the temporary variable to be decomposed and the first assignment, modify its name. (2) Declare the new temporary variable as final. (3) The second assignment of the temporary variable is bounded, and all references to the temporary variable are modified to refer to the new temporary variable. (4) at the second assignment, re-declare the original temporary variable. (5) compile, test. (6) Repeat the above process at successive repeats. Each time the temporary variable is renamed at the Declaration and the reference point before the next assignment is modified.

Examplelet's start with a simple calculation: we need to calculate the distance of a Scottish pudding movement. At the beginning, the resting pudding is subjected to the action of an initial force and begins to move. After a while, the second masterpiece is used for the pudding, which accelerates it again. According to Newton's second law, the distance of the pudding motion is calculated:

Double getdistance (int time) {double result;double acc = _primaryforce/_mass;int primarytime = Math.min (time, _delay); res ult= 0.5 * ACC * primarytime * primarytime;int secondarytime = time-_delay;if (Secondarytime > 0) {Double primaryvel = ACC *_DELAY;ACC = (_primaryforce + _secondaryforce)/_mass;result + = Primaryvel * secondarytime + 0.5 * ACC * Secondaryti Me * secondarytime;} return result;}

The code seems a little ugly. Observe how the ACC variable in the example is assigned two times.
The ACC variable has two responsibilities, one is to save the acceleration generated by the first force, and the other is to save the acceleration generated by the two forces together. This is what needs to be decomposed.

First, modify the name of the temporary variable at the beginning of the function and declare the new temporary variable final. Then, after assigning the second assignment to all the reference points of the ACC variable, all the temporary variables of the intentions are changed. Finally, the ACC variable is re-declared at the second assignment.

Double getdistance (int time) {Double result;final double PRIMARYACC = _primaryforce/_mass;int primarytime = math.min (Time , _delay); result= 0.5 * PRIMARYACC * primarytime * primarytime;int secondarytime = time-_delay;if (Secondarytime > 0) { Double primaryvel = PRIMARYACC *_delay;double acc = (_primaryforce + _secondaryforce)/_mass;result + = Primaryvel * Secon Darytime + 0.5 * ACC * secondarytime * SECONDARYTIME;} return result;}

The new temporary variable indicates that it only assumes the first responsibility of the original ACC variable. Declare it as final and make sure it is assigned only once. The ACC is then re-declared at the second assignment of the ACC variable. Now, recompile and test, everything is fine. then proceed with the second assignment of the ACC temp variable.

Double getdistance (int time) {Double result;final double PRIMARYACC = _primaryforce/_mass;int primarytime = math.min (Time , _delay); result= 0.5 * PRIMARYACC * primarytime * primarytime;int secondarytime = time-_delay;if (Secondarytime > 0) { Double primaryvel = Primaryacc *_delay;final Double SECONDARYACC = (_primaryforce + _secondaryforce)/_mass;result + = pri Maryvel * secondarytime + 0.5 * SECONDARYACC * secondarytime * secondarytime;} return result;}

Now, I think you will think of some of the previous articles in some of the refactoring techniques, then enjoy the use of it.

"Replace temporary variable with query" technique for refactoring double getdistance (int time) {Double result= 0.5 * GETPRIMARYACC () * Getprimarytime (TIME) * Getprimarytime (Time), if (Getsecondarytime (time) > 0) {result + = Getseconddistance ();} return result;} Private double Getprimaryacc () {return _primaryforce/_mass;} Private double Getsecondaryacc () {return (_primaryforce + _secondaryforce)/_mass;} private int Getprimarytime (int time) {return math.min (time, _delay);} private int Getsecondarytime (int time) {return time-_delay;} Private double getseconddistance () {return GETPRIMARYACC () *_delay * Getsecondarytime (TIME) + 0.5 * GETSECONDARYACC () * get Secondarytime (Time) * Getsecondarytime (time);}

 This paper mainly introduces the refactoring technique-decomposition of temporary variables. The reconstruction technique is mainly aimed at the cases where the variables are assigned multiple times. Once the temporary variable in the function is more, and is assigned several times, it is more prone to problems, reading the code is very laborious, it is necessary to adjust it to make it neat. In addition, you can see from the above example that when you use a refactoring technique, you don't always think about other refactoring techniques, and you're directing your code better. Finally, I hope this article will be of some help to you. There are questions to leave a message, thank you. (PS: The next article will describe the refactoring note-removing the assignment of parameters)

The refactoring Note article is as follows

Refactoring Notes-Introductory article

Refactoring notes-bad taste of code (UP)

Refactoring notes-bad taste of code (bottom)

Refactoring notes-building a test body

Refactoring notes-Refining functions

Refactoring notes-inline functions

Refactoring notes-Inline temporary variables

Refactoring notes-replacing temporary variables with queries

Refactoring notes-Introduction of explanatory variables

Refactoring notes-breaking temporary variables