How To Refactor
How To RefactorThis could be a place to tell how in practice the ideas of ReFactoring can be enforced.
Is there a convention on Wiki for locating this kind of page?
Q: I have a question about how to do the ReFactoring in practice (as I am not professional programmer, this may be a kind of newbie question). Let's say for example I have veeeeery long method that parses through a text (to convert it or something). Now did I understand the ReFactoring idea correctly, that it should be my goal to shorten the method? And to break it up into several smaller ones?
The problem comes when I take a bit of the long method out (perhaps even lines that I can reuse somewhere), and create a new method with it. Then I have to give to this method all the arguments it needs, in this example perhaps the number of chars in the text, the number of words, or the point where I am in the converting process... and so on. And when the method has done its work, it has to give the all the stuff it modified back again. Doesn't this make the code longer - and more complicated?
Wouldn't I have to check the passed arguments for validity in the method, to be on the sure side?But this would again lead to even more LinesOfCode. And when I have split the long method up - wouldn't this lead to code where I have to jump around a lot to read what it does?
So in short: All the overhead that comes with the splitting of the method, makes it hard (less fun) to ReFactor and the code might even gain LOC. Am I doing/thinking something wrong here? (Ok, this was a long question - perhaps it would make a own page?)
2004-07-03
A: I'll bite, though I haven't worn a professional programming hat in years. From my experience with refactoring, LinesOfCode isn't the big issue; clarity is. When I've got a complicated logical test embedded in a chunk of code, say
if (customer.age < 65 and customer.yearlyAmortizationPayout > maxYearlyPayout) ...I refactor it to something that expresses the intent of the test:
if (overPaying(customer)) ...Yes, I'll have to jump elsewhere to find the definition of overPaying, but I've found that my code is easier to read because more of it expresses what it's meant to do, rather than how it does it. Total code is longer, true, but more comprehensible.
The other big payoff is that all those ShortMethods are much easier to UnitTest than a few monolithic methods.
If it gets too complicated, then a MethodObject could be a great help too.
Q: If I have a class which works, but in light of upcoming changes should probably be thrown out and redesigned. Much of existing use of the class would be altered to follow different conventions. What's the best way to refactor? I propose this method:
A: Engineers seek ways to cause the next problem they intend to solve. Start to make the upcoming changes, focusing on the ones you expect to cause problems. The problems will tell you what do do with the design.
See ReFactor, ReFactoring, WhatIsRefactoring, RefactorMercilessly, RefactorDaintily, DeprecationRefactor
EditText of this page
(last edited February 23, 2005)
or FindPage with title or text search