Directed Refactoring

This is a "process pattern" that I have been using successfully -- AamodSane

Precondition: You know, perhaps from previous experience, how to design a general framework for your problem. But building frameworks means you cannot deliver visible business function quickly. Furthermore, if your assessment is wrong (however small the chance), you will have wasted a lot of time.

Therefore: Direct your architecture such that you know that you can refactor it later to create your desired framework.

Example:

(This is a bit naive, but illustrates the point. The real life examples I have are either too big or proprietary). You have to design a data structure library. You know the STL is a good design, you want to emulate it. You need a linked list with sort today. So build a simple list using "next" pointers. Write a sort in its own class; use general names and types in it, such that writing an iterator based sort would be easy. Special case it for the linked list. The next time you need to use it on an array, refactor it and build the iterators in.

Why not just write the linked list with a sort function in it. Later when you want to use it on an array begin your refactoring by moving sort into its own class and making the names more general.

The problem with preparing for a future refactoring by putting sort in a separate class is that it will take slightly longer for another developer to understand what you are doing. The more preparation code or future code you have sprinkled in your real code the longer it will take someone else to understand it.

-- AsimJalis

See also: http://st-www.cs.uiuc.edu/users/droberts/evolve.html, Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks, by DonRoberts and RalphJohnson.

Merged from DesignForRefactoring

Is there such a thing? I thought of this in relation to DirectedRefactoring. We often speak of well factored code, and all of us have seen people write nightmarish loops with lots of state variables and flags. Some of this also hearkens back to good old CouplingAndCohesion.

-- AamodSane

Hypothesis:

Some architectures lead to easily refactorable programs, others not.

Hypothesis:

A program is "more easy to refactor" if a "small" refactoring of the code has a "small" effect on related code.

A simple rule in Smalltalk with the refactoring browser - don't reuse selectors from the image if you mean something different than the general meaning. I called a method "value" the other day and then had to painfully refactor by hand (doing type and flow analysis) because I couldn't do a rename ("value" is implemented in many places).

I think there's Coding For Refactorability, but not Design. Now certainly it would be possible to design and then build a system that was hard to refactor, but to do this you would have to put methods on the wrong objects, combine instance variables with different lifespans, etc., etc. And when you began to type things in, you'd encounter multiple implementations of the same thing, and other clues that you needed refactoring. Then you would, of course, ignore those clues, because you were following the (bad) design.

By starting with DoTheSimplestThingThatCouldPossiblyWork, and RefactorMercilessly, you keep the system clean. Once it's out of hand, the problem can be seen in the design, but it really happened in the coding.

See: http://web.archive.org/web/20030223153901/http://www.xpsd.com/RefactoringDemo

CategoryRefactoring