Evaluation and improvement of software architecture
Νικόλαος Τσάνταλης · 2010
class Change has several subclasses representing various types of changes that may occur in the Eclipse workbench. In the case of refactorings on Java source code the most suitable type of Change is CompilationUnitChange which is a special TextFileChange that operates on an ICompilationUnit in the workspace. In order to create an operational CompilationUnitChange object, the TextEdit resulting from a single ASTRewrite or the MultiTextEdit resulting from the aggregation of multiple TextEdits resulting from different ASTRewrites should be set to the CompilationUnitChange through method setEdit(TextEdit edit). Additionally, all subtypes of TextChange (such as CompilationUnitChange) allow to define TextEditGroups through method addTextEditGroup(TextEditGroup group) in order to present parts of the change modifications as different preview groups. This allows to preview the changes in a CompilationUnit as multiple groups of text modifications and not as a single text modification covering the entire CompilationUnit. Figure 6.12 shows a case of Extract Method refactoring where the change modifications occurring within the body of the original method are captured by a different preview group compared to the group of change modifications that create the extracted method. Obviously, in this way the user can more easily discriminate the change modifications imposed by complex refactoring transformations. Figure 6.12: Representation of TextEditChangeGroups in a CompilationUnitChange. The code of Figure 6.13 contains a typical implementation of method createChange() for a single CompilationUnitChange that can be easily extended for refactorings affecting more than one CompilationUnits. The final part of this implementation creates a CompositeChange object which facilitates the composition of multiple Changes into a single one. The created CompositeChange object should override method getDescriptor() to return an instance of RefactoringChangeDescriptor which in turn encapsulates a RefactoringDescriptor instance. A refactoring descriptor contains refactoring-specific data which allows the framework to completely reconstruct a particular refactoring instance and execute it on an arbitrary workspace. In other words, a refactoring descriptor enables the execution of a redo operation for a refactoring which has been undone in the refactoring history of the Eclipse workbench.