The name of this change/refactoring pattern

Question

At first, we have a working function name foo

void foo() { 
 bar1(9); 
 bar2(9); 
}

Noted that the value 9 is hard-coded. Then, we want to make a change so we can make 9 a parameter yet preserving the old foo function, so we change it to

void foo() {
 foo_ex(9);
}
void foo_ex(int x) {
 bar1(x);
 bar2(x); 
}

Coding-wise, this is usually done by one way of following

1. Replacing the line void foo() to void foo_ex(int x) and then re-create foo function that in turns call foo_ex
2. Declaring a new foo_ex function, move the body of foo function to foo_ex and replacing hard-coded value with parameter x, and then call foo_ex from foo

The question is, is there any name for this pattern? It is not a complex pattern but I usually take some time to communicate this and the pattern arises quite often.

• Kilian Foth: All of my IDEs call this "Extract Parameter", which is a perfectly good descriptive phrase. I don't think a custom name would be an improvement.
• Greg Burghardt: Does code elsewhere have an immediate need to call foo_ex with different values? Otherwise I would call this "unnecessary."

Answer 1

The refactoring from

void foo() { 
 bar1(9); 
 bar2(9); 
}

to

void foo() {
 foo_ex();
}
void foo_ex() {
 bar1(9);
 bar2(9); 
}

is called Extract Function, as mentioned by Thomas Owens. However, replacing the hardcoded value is not part of that step. The step to

void foo() {
 foo_ex(9);
}
void foo_ex(int x) {
 bar1(x);
 bar2(x); 
}

is called Parameterize Function. It max be also seen as a special case of Change Function Declaration.

When you want to know the name of certain refactorings, it is a good idea to check Martin Fowler's catalog first, since his list is the canonical source for most standard refactorings.

Answer 2

This is an example of the Extract Function refactoring. The application of Extract Function may result in a method that takes no arguments and calls bar1() and bar2() with a hard-coded value of 9, so a refactoring like Extract Variable could separate the steps, but I'm not sure that I'd make that distinction.

When it comes to naming the extracted function, Naming as a Process provides some guidance that using a nonsense name can make it obvious that the extraction either needs a better name or more refactoring to create a better organization to be able to give it a better name. You may initially want to follow this approach with a nonsense name for foo_ex() and then find a new name later. This is specifically discussed in Get to Obvious Nonsense.

• tia: Yes, it can be done by extracing function as a step, but it is not just extracting it. It is like extract function, promote hard-coded value in extracted function to be a parameter and put the hard-coded value back to the original function, which usually takes time to communicate. Naming as a process is interesting though.
• Thomas Owens: @tia When refactoring, each step has a name. There wouldn't be a name that encompasses all three steps. I don't think you are promoting a hard-coded value because no signature is changing. You are giving your extracted function an argument at the time of creation. Since your new extracted function needs an argument, then you need to provide it into the caller at the time of extraction or else the code will be broken (and it's not a refactoring). If I had to describe this refactoring to someone, I would just use the term Extract Function.