Refactoring Proposals

This page lists proposed refactorings and their status. By clicking on a refactoring you can get to its specification. Refactoring menu items should ordered according to this specification.

Refactoring	Status	Specification	Implementation	User Interface
Pull Up	final	Done	Done	Done
Push Down	final	Done	Done	Done
Extract Method	final	Done	Done	Done
Replace Method Code Duplicates	experimental	Done	In progress Bharath Ravikumar	In Progress Bharath Ravikumar
Extract Interface	final	Done	Done	Done
Extract Super Class	final	Done	Done	Done
Use Supertype Where Possible	final	Done	Done	Done
Generify	experimental	Done	-	-
Convert Anonymous To Nested	final	Done	Done	Done
Move Inner To Outer Level	final	Done	Done	Done
Copy Class	experimental	Done	In progress Jan Becicka	In progress Jan Becicka
Move Method	experimental	Done	In Progress Zithulele Basil Shange	In Progress Zithulele Basil Shange
Inline (method/variable)	experimental	Done	-	-
Introduce Variable	experimental	Done	In progress Daniel Prusa	In progress Daniel Prusa
Safe Delete	final	Done	Done	In Progress Bharath Ravikumar
Clean-Up	experimental	Done	In progress Leon Chiver	In Progress Leon Chiver
Use Field Instead of Literal	In progress	In progress	-	-

Status: experimental - developed in experimental module / final - moved to the refactoring module

Are you missing your favorite refactoring? Or does some of the refactoring specifications contain a bug or is it not covering an important use-case? Please let us know at dev@refactoring.netbeans.org.

Specification Structure

The refactoring specifications are divided into several sections based on the flow that the refactoring framework in NetBeans enforces. In NetBeans every refactoring is implemented using a non-visual class that implements the whole refactoring logic. A refactoring (or several refactorings together) can then be visualized using UI classes that plug into the NetBeans Refactoring UI framework. So, the logic and the UI are described separately in the spec.

The pre-conditions section in the specification describes what type of objects the refactoring can be invoked on. Typically this indicates what the refactoring class accepts in its constructor. Then the refactoring object goes through the following phases:

1. Pre-Check: Complex check of the preconditions - this typically includes complex queries to the Java metadata to find out whether there are any problems with performing refactoring on a given element.
2. Setting Parameters: A refactoring client parameterizes the refactoring (e.g. in case of "Rename" refactoring the client provides a new name). The specification defines what the parameters of the refactoring are.
3. Fast Parameters Check: In this phase the refactoring does some basic checks of the parameter values. The checks during this phase must be simple, since the fast check is invoked from the refactoring UI very frequently.
4. Parameters Check: Other checks of parameter values that are not done in the "Fast Parameters Check" phase. These are typically some more complex checks computation of which may require a significant amout of time (a progress bar may be necessary in the UI layer).
5. Preparation Of The Changes: In this phase the refactoring computes all the changes that need to be performed as part of the refactoring.
6. Checks During Changes Preparation: Additional checks that may be done during computation of the changes.

For more information on the NetBeans Refactoring API framework please see Refactoring API Javadoc.