Composing Methods: Substitute Algorithmn
Posted on 15/8/07 by Tim Koschützki
When you want to replace an algorithmn with one that is clearer, replace the body of the method with the new algorithmn.
Motivation
This often does not appear as a real refactoring. However, "Substitute Algorithmn" should not be underestimated. It's really something we should do all the time.
If you find a clearer way to accomplish something, you should replace the complicated way with the easier one.
Remember this important statement: "Do the simplest possible thing." Designing systems is so hard already - why should you go out of your way to make the task even harder?
Break complex things up into simpler things, and let each solve a piece of the puzzle. Gaius Julius Cesar had the right idea with his "Divide and Conquer" approach.
Programming is such a dynamic action that you often find yourself having to replace an algorithmn alltogether. It will be much easier to do if the current algorithmn is an easy one already.
Also, you may start using a library and thus your code may be subject to duplication. Substitute the corresponding algorithmns and get rid of the duplication.
Make sure you decompose your algorithmns as much as you can and use many small methods for it.
Mechanics
- Prepare your alternative algorihtmn.
- Run your new algorithmn against your unit tests. If the results are the same, you are finished.
- If the results are not the same, run each test case with the old a new algorihtmn and solve those that fail.
Example
Before:
$numPeople = count($people);
for($i=0;$i<$numPeople;$i++) {
if($people[$i] == "Tim") {
return "Tim";
}
if($people[$i] == "Felix") {
return "Felix";
}
if($people[$i] == "John") {
return "John";
}
}
return "";
}
After:
You can skip to the end and add a comment.
Other alternative doing the same, but with less code:
function foundPerson($people = array()) {
$matches = array_intersect($people, array(”Tim”, “Felix”, “John”));
return empty($matches) ? null : $matches[0];
}
Good call, thanks. :)
"Make sure you decompose your algorithmns as much as you can and use many small methods for it."
As a rule of thumb I try to keep my methods under 25 lines. I've seen methods that are over 60 lines ... very scary. I have nightmares about those.
deltawing1: Well I agree that sometimes you just have to write more than say 25 lines. Breaking the code up could make it less understandable. But this happens very rarely.
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.
[...] Koschuetzki has another in his “Composing Methods” series posted today - this one taking a look at something called the “substitute algorithm”. It’s a method of [...]