Refactoring means behavior-preserving program transformations. The JDT supports a number of transformations described in Martin Fowler's book Refactoring: Improving the Design of Existing Code, Addison Wesley 1999.
When performing a refactoring, you can optionally preview all the impending changes resulting from a refactoring command before you finally choose to carry it out.
Depending on the context from which you choose to refactor, various refactoring commands are available.
Element |
Available Refactoring Commands |
---|---|
Package |
Rename |
Compilation unit |
Rename Move to another package |
Type |
Rename |
Method |
Rename Rename parameters |
Code |
Extract Method |
You can rename an element, and the workbench's refactoring support changes both the selected resource's name and all references to it.
You can rename the parameters of a method by renaming the parameter's declaration as well as all references to the parameters inside the method body. Use the Rename Parameters command to rename the parameters of a method as well as all references to these parameters. On the refactoring parameters page, you can click in the New Parameter Names column on the row containing the parameter you want to change and type a new name for the parameter.
You can move a compilation unit to a different package. Imports and references are automatically updated.
When you extract a method, the workbench extracts a range of code from an existing method body and creates a new method for it, also adding a call from the old method to the new method. This feature is useful for cleaning up lengthy, cluttered, or overly-complicated methods.
You can execute a refactoring in one of two different ways.
In a quick refactoring, you skip being notified of potential problems and the refactoring preview. If a Stop problem is predicted, the refactoring will not be carried out.
In a controlled refactoring, you are notified of potential problems and are given a detailed preview of what the refactoring action will do.