Lecture
A significant proportion of refactoring is devoted to a fair generalization of methods. In the bulk of the situation, the basis of many ills is considered very large methods. The entanglement of the program code from inside this method, hide the execution logic and accomplish the method is very difficult for the purpose of understanding, and means changes. Refactoring of this category is caused by reducing the complexity from the inside of the method, removing duplicate program code and simplifying its further support.
Extract method
Method embedding
Extract variable
Variable embedding
Replacing a variable with a method call
Variable splitting
Deleting assignment parameters
Replacing a method with a method object
Method replacement
1. Removing the method
Problem
You have a code snippet that you can group.
Select a section of code in the new method (or function) and call this method instead of the old code.
function printOwing () {
$ this -> printBanner ();
// print details
print ( " name:" . $ this -> name );
print ( " amount" . $ this -> getOutstanding ());
}
function printOwing () {
$ this -> printBanner ();
$ this -> printDetails ( $ this -> getOutstanding ());
}
function printDetails ( $ outstanding ) {
print ( " name:" . $ this -> name );
print ( " amount" . $ outstanding );
}
The more lines of code in a method, the more difficult it is to figure out what it does. This is the main problem that this refactoring solves.
Extracting a method not only kills a lot of snuffs in the code, but is also one of the steps of many other refactorings.
Improves readability of the code. Try to give the new method a name that reflects the essence of what it does. For example, createOrder()
, renderCustomerInfo()
, etc.
Removes duplicate code. Sometimes code rendered in a method can be found elsewhere in the program. In this case, it makes sense to replace the found code sections with a call to your new method.
Isolates independent parts of the code, reducing the likelihood of errors (for example, the fault of overriding the wrong variable).
Create a new method and name it so that the name reflects the essence of what this method will do.
Copy your worried code snippet to a new method. Remove this fragment from the old place and replace with a call to your new method.
Find all the variables that were used in this code snippet. If they were declared inside this fragment and are not used outside it, just leave them unchanged - they will become local variables of the new method.
If variables are declared before a section of code that interests you, then they should be passed to the parameters of your new method in order to use the values that were previously in them. Sometimes it is easier to get rid of such variables by replacing the variables with a method call.
If you see that a local variable somehow changes in your part of the code, this may mean that its modified value will be needed further in the main method. Check this. If the suspicion is confirmed, the value of this variable should be returned to the main method in order not to break anything.
Comments
To leave a comment
Refactoring theory
Terms: Refactoring theory