The name of a method must have a higher level of abstraction than the body for the method to be worth it. The name should explain what the method does but not how. If the name communicates exactly the same than its code, it could be a sign that the method does not pay off and should be inlined.
Whenever we extract a method from a bunch of lines of code, we are adding a little abstraction to our code. If the extraction happens too early, then we are adding wrong abstractions to the code. Those premature abstractions get in our way to a better design, often hiding duplication and deeper design problems. Lots of small methods does not necessarily mean better design.
I extract a method only when my tests are green and it’s really obvious the responsibility of those lines. When I am done implementing the branch of the solution I am test-driving and it’s easy to find a name for the new method. I don’t create new methods to make a test pass. Methods appear later.
Code below is an example of premature method extraction. Right after the first test passed the developer created this method:
private boolean isValidArithmeticExpression(String input) {
return input != null;
}
The body of the method is perfectly understandable without the method. There was no duplication of the statement and there were just a few lines in the production code. Definitely too risky, too early, too complex.
An example of a wrong encapsulation:
public string splitBySpace(string expression){
return expression.split(" ");
}
In this example the method’s name says exactly what one can read in the body.
The same applies to helper methods in the tests. This is an example of a wrong encapsulation:
private void conductCalculationAndAssertResult(String equation, int expectedResult) {
int result = calculate(equation);
assertEquals(expectedResult, result);
}