However, if we learn to think in terms of the "atomic" refactorings, large redesigns are much less daunting. In high school math, they taught us how to solve problems like "What number divided by 6 is 3 less than itself." Initial attempts involve trial and error. Then they teach you to represent the problem as x/6=x-3. This doesn't really bring us any closer to the solution. BUT, then they taught us how to manipulate the equation with operations such as "Add the same number to both sides."
Now, solving the complicated problems now is easy because the manipulations are the terms in which I think. Whether you have a tool to perform the operations for you automatically or if you have to do the operations manually, does not make as much difference as the manner in which you think about the problem.
To be quite honest, I rarely think of refactoring code to achieve a particular GoF DesignPattern. Usually, the CodeSmells and I'm trying to alleviate the odor. After the fact, I can look at what I've done and identify it as one of the patterns. --DonRoberts
Most of my refactorings (until now) have had the goal of making the code easier to understand. -- AsimJalis
X-3 = X/6 6(X-3) = 6X/6 6X - 18 = X 5X - 18 = 0 5X = 18 X = 18/5 or 3 3/5In other words, very small steps can get you all the way.
18/5 - 3 = 18/5 - 15/5 = 3/5 18/5 * 1/6 = 18/30 = 3/5
Note that, if you attempt to test the above in a programming language, you may get an inexact answer as a result of machine floating-point arithmetic. The true arithmetical answer is exact and correct.
This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006