Refactoring notes-inline functions, refactoring inline functions

Refactoring notes-inline functions, refactoring inline functions

This article is in the study of the summary, welcome to reprint but please note the Source: http://blog.csdn.net/pistolove/article/details/42261333

In the previous article, we introduced "extraction functions". This article introduces the refactoring method of "inline functions.

Let's take a look at this refactoring technique.

Open door

Discovery: the ontology and name of a function are as clear and easy to understand.

Solution: insert the function Ontology at the function call point and remove the function.

// Public int getRating () {return (moreThanSixLateDeliveries () before refactoring ())? 2: 1;} boolean moreThanSixLateDeliveries () {return _ numberOfLateDeliveries> 6 ;}

// Public int getRating () {return (_ numberOfLateDeliveries> 6) After reconstruction )? 2: 1 ;}

Motivation

In the refactoring process, short functions are often used to express the action intent, which makes the code clearer and easier to read. But sometimes you may encounter some functions, and their internal code and function names are as clear and easy to read. You may have reconstructed the function to make its content as clear as its name. If so, you should remove this function and use the Code directly. Indirectly may bring some help, but there is no need to indirectly make people feel uncomfortable.

Another case is that you have a group of functions that are not reasonably organized. You can inline them into a large function, and then extract small functions that are reasonably organized. Moving a large function as a whole is easier than moving a function or all other functions called by it.

If you find that too many indirect layers are used in the code, it seems that all the functions in the system are just a simple delegate to another function, resulting in dizzy turns caused by some delegate actions, in this case, inline functions are usually used.

Method (1) Check the function to determine that it does not have polymorphism. (If the subclass inherits this function, do not inline this function, because the subclass cannot re-write a function that does not exist at all ). (2) Find all called points of this function. (3) Replace all called points of the function with the function ontology. (4) Compile and test. (5) After everything is normal, delete the definition of the function.

Inline functions seem simple. But this is often not the case. For recursive calls and inner links to another object, but this object does not provide access functions... every situation is complicated. If you encounter such a complicated situation, you should not use this refactoring method.

This article mainly introduces the refactoring method-inline function, which is simple to handle. To put it bluntly, it is to eliminate a function and move the code to the place where the function is used. Although the method is relatively simple, it is often used in the development process. I hope this article will help you. If you have any questions, please leave a message. Thank you. (PS: the next article will introduce refactoring notes-inline temporary variables)