CSC/ECE 517 Fall 2009/wiki1a 9 mk: Difference between revisions
| Line 22: | Line 22: | ||
===Features of some Refactoring Tools=== | ===Features of some Refactoring Tools=== | ||
Refactoring tools can be grouped into three broad categories | |||
(and this is the order in which they appear in the Refactoring menu): | |||
Changing the name and physical organization of code, including renaming fields, variables, classes, | |||
and interfaces, and moving packages and classes | |||
Changing the logical organization of code at the class level, including turning anonymous classes | |||
into nested classes, turning nested classes into top-level classes, creating interfaces from | |||
concrete classes, and moving methods or fields from a class to a subclass or superclass | |||
Changing the code within a class, including turning local variables into class fields, turning | |||
selected code in a method into a separate method, and generating getter and setter methods for | |||
fields | |||
Several refactorings don't fit neatly into these three categories, particularly Change Method | |||
Signature, which is included in the third category here. Apart from this exception, the sections | |||
that follow will discuss Eclipse's refactoring tools in this order. | |||
====Java Refactoring Tool, Eclipse==== | ====Java Refactoring Tool, Eclipse==== | ||
| Line 29: | Line 45: | ||
====Ruby Refactoring Tool, Aptana==== | ====Ruby Refactoring Tool, Aptana==== | ||
====.NET Refactoring Tool, Visual Studio IDE==== | ====.NET Refactoring Tool, Visual Studio IDE==== | ||
==Academic Underpinning== | ==Academic Underpinning== | ||
Revision as of 19:50, 6 September 2009
Research in Refactoring Tools
Refactoring
Refactoring is the process of modifying existing source codebase in a structured and incremental way while preserving its external behavior. This process preserves the functionality of the program without introducing new bugs. Refactoring also promotes reuse of the existing codebase for other purposes thus increasing code reusability.
Overview
The fundamental work is primarily focused on the definitions and mechanism of refactoring, and proving their correctness. Refactoring means that the behaviour/functionality of the program does not change and therefore any program which meets its specifications before refactoring will continue to meet those specifications even afterwards. Refactoring can be done on any codebase and it is a general set of operations. Hence it comes with preconditions which specifies under what circumstances refactoring can be performed, also with the conformation that the dependency graphs are unchanged even after the refactoring is performed.
Current Automated Refactoring Tools
Features of some Refactoring Tools
Refactoring tools can be grouped into three broad categories (and this is the order in which they appear in the Refactoring menu):
Changing the name and physical organization of code, including renaming fields, variables, classes, and interfaces, and moving packages and classes
Changing the logical organization of code at the class level, including turning anonymous classes into nested classes, turning nested classes into top-level classes, creating interfaces from concrete classes, and moving methods or fields from a class to a subclass or superclass
Changing the code within a class, including turning local variables into class fields, turning selected code in a method into a separate method, and generating getter and setter methods for fields
Several refactorings don't fit neatly into these three categories, particularly Change Method Signature, which is included in the third category here. Apart from this exception, the sections that follow will discuss Eclipse's refactoring tools in this order.