Refactoring

Here is a common situation where refactoring can be used:

Problem:

You have a body of code which exposes and API (set of entry points). You want this code to have a different API.

Non-refactoring based solution:

Take the old code apart. From the pieces, write new code that has the desired API. The problem with this is that it’s a big leap… with little confidence along the way that the code will work.

Refactoring based solution:

Create a empty implementation of the desired API. Use the old code’s API to implement these functions – create a wrapper around the old code. Verify (with unit tests) that the code does what you want, using the desired API.

Now, consider the “wrapper” and the old code as a body of code to be refactored… incrementally change it to improve the design, maintainability, etc.

Alternatively, if the code is “throw-away” code not of long term important, you have the option to stp – just leave the code wrappered and un-refactored.

Right now, most refactoring is happening “manually” – but in the future, a direction that IDEs can add more value is by automating the process. Imagine right-clicking a method and selecting “refactor up to superclass”. You can take a look at this idea with a tool that “adds-in” refactoring to your existing IDE, like TransMorgify. A new Java IDE, IntelliJ IDEA offers a limited set of refactoring tools, built in to the IDE.