You have a big algorithmic method. Let's break it.
TL;DR: Long methods are bad. Move them and break them.
Problems Addressed π
https://coderlegion.com/8662/code-smell-10-too-many-arguments
https://maximilianocontieri.com/code-smell-21-anonymous-functions-abusers
https://maximilianocontieri.com/code-smell-36-switchcaseelseifelseif-statements
https://coderlegion.com/7617/code-smell-03-functions-are-too-long
https://maximilianocontieri.com/code-smell-112-testing-private-methods
https://maximilianocontieri.com/code-smell-206-long-ternaries
Context π¬
Sometimes, a method is so complex that Extract Method isn't enough.
When you break a long algorithm, you end up with too many local variables.
You pass them as parameters between every new sub-method.
This "parameter pollution" signals the algorithm wants its own identity.
When you extract the method into a Method Object, you create a new class.
Local variables become private attributes of that class.
This creates a sandbox for decomposing the algorithm into tiny, cohesive steps.
The original host class stays clean and uncluttered.
You transform a rigid procedure into a testable, reusable component.
It can eventually evolve into a full
Strategy pattern.
Steps π£
Create an object to represent an invocation of the method.
Move the big method to the new object.
Convert the temporary variables of the method into private attributes.
Break the big method in the new object by using
https://maximilianocontieri.com/refactoring-002-extract-method
Remove parameters from method invocation. Convert them to private attributes.
Sample Code π»
Before π¨
class BlockchainAccount {
// ...
public double balance() {
String address;
// Very long untestable method
}
}
After π
class BlockchainAccount {
// ...
public double balance() {
return new BalanceCalculator(this).netValue();
}
}
// 1. Create an object to represent an invocation of the method
// 2. Move the big method to the new object
// 3. Convert the temporary variables
// of the method into private attributes
// 4. Break the big method in the new object
// by using The Extract Method
// 5. Remove parameters from method invocation
// by also converting them to private attributes
class BalanceCalculator {
private String address;
private BlockchainAccount account;
public BalanceCalculator(BlockchainAccount account) {
this.account = account;
}
public double netValue() {
this.findStartingBlock();
//...
this computeTransactions();
}
}
Type π
[X] Semi-Automatic
Some IDEs have tools to extract a function into a method object.
Safety π‘οΈ
This is a syntactic and structural refactoring.
You can make these changes safely with IDE tools.
Why is the Code Better? β¨
You extract the logic into a new, testable component.
You can unit-test it or swap it for a different strategy.
How Does it Improve the Bijection? πΊοΈ
A long method hides several real-world concepts inside one opaque procedure.
When you extract it into a dedicated object, each step gets its own name.
Code should map to the real world, as described in the
Bijection.
Every concept in the domain needs a counterpart in the code.
That's the core idea of the
MAPPER.
The algorithm's partial state becomes attributes, and its steps become methods.
The object's name describes what it computes.
Level π
[X] Intermediate
https://maximilianocontieri.com/refactoring-002-extract-method
https://coderlegion.com/8309/refactoring-037-testing-private-methods
Refactor with AI π€
Suggested Prompt: 1. Create an object to represent an invocation of the method.2. Move the big method to the new object.3. Convert the temporary variables of the method into private attributes.4. Break the big method in the new object by using Extract Method.5. Remove parameters from method invocation by also converting them to private attributes.
Conclusion π
The Method-Object suits cases where you use several extract methods.
These methods pass partial state among them as algorithm steps.
The method object stores these partial computations in its internal state.
A clear sign is when computations don't relate cohesively to the host method.
You can also apply this technique to
anonymous functions.
The result is an atomic, testable method object.
See also π
https://en.wikipedia.org/wiki/Strategy_pattern
https://learning.oreilly.com/library/view/smalltalk-best-practice/9780132852098/ch03.xhtml
https://refactoring.guru/es/replace-method-with-method-object
https://wiki.c2.com/?MethodObject
Credits π
Image by Manuel de la Fuente from Pixabay
This article is part of the Refactoring Series.
https://coderlegion.com/13921/how-to-improve-your-code-with-easy-refactorings