The Smalltalk community was the first one which used refactorings consistently during the development process and many of the contributors like RALPH JOHNSON, KENT BECK, DON ROBERTS, MARTIN FOWLER et.al. originated from there, the development of the Refactoring Browser was only a logical step within the development. Fortunately the Smalltalk programming environment provides ideal conditions for implementing such an tool, as is later cited in this section.
Because of my shortcomings - I do neither have access nor knowledge of the Smalltalk programming language - I am not able to provide firsthand information about the tool but rather cite the authors [TAPOS] first as well as an enthusiastic user [Wiki, RefactoringBrowser-Kent Beck,]:
Since refactoring occurs at all levels within the software development life cycle, the ability to perform refactorings automatically is crucial to software evolution.
The Smalltalk Refactoring Browser is a tool that carries out many refactorings automatically, and provides an environment for improving the structure of Smalltalk programs. It makes refactoring safe and simple, and so reduces the cost of making reusable software.
The goal of our research is to move refactoring into the mainstream of program development. The only way that this can occur is to present refactorings to developers in such a way that they cannot help but use them. To do this, the refactoring tool must fit the way that they work. This goal imposes the following design criteria on the Refactoring Browser:
Our approach is to provide a tool that will search for places in your program where code is duplicated, or unused, and point them out. This allows a human to make the final call whether or not the code should be consolidated and to provide a semantically meaningful name.
There are some features of the Smalltalk language and the development environment Visual Works that allow an easier application of refactorings:
The static properties of the program must be analyzed to determine if these preconditions are satisfied before performing a refactoring. ...Since we reused many of the existing static checks present in the compilation framework, the refactoring framework is much simpler than it would be if we had implemented all of these checks ourselves.
The major drawback to this type of refactoring is that the refactoring is only as good as your test suite. If there are pieces of code that are not executed, they will never be analyzed, and the refactoring will not be completed for that particular section of code.
It is intended by the authors of the tool to extend it to enable users to do their refactorings even quicker and without reluctance:
Refactoring is a common operation in the software life cycle and the Refactoring Browser provides automatic support for many of the common transformations that come up in Smalltalk development. The Refactoring Browser is a practical tool in that it can perform correct refactorings on nearly all Smalltalk programs. In fact, we regularly use the Refactoring Browser on itself. That is, we use the tool to refactor its own source code. Additionally, the Refactoring Browser has been used to help develop a wide range of frameworks from the HotDraw framework for graphical editors, to financial models being developed by Caterpillar, to prototypes and models for a major telecommunications company.
Now KENT BECK shares [Wiki, RefactoringBrowser-Kent Beck,] his experiences with the Refactoring Browser:
This is absolutely the greatest piece of programming software to come out since the original Smalltalk browser. It completely changes the way you think about programming. All those niggling little "well, I should change this name but..." thoughts go away, because you just change the name because there is always a single menu item to just change the name....
The best thing about Refactory is how safe it is. As long as you don't manually edit the source code, you are nearly guaranteed (modulo things like choosing the wrong class for a "move to component") that you won't change the semantics of the program. The more I use it, the more aggressive I am slamming logic around until it makes sense.
Changing names is the least of its tricks. Some others are:
Some other cool tricks:
- Extract Method - make a sub-method out of the selected text. If there is already an equivalent method, optionally invoke that instead.
- Inline Method - put the invoked code in place of the invocation. This even works for methods in other classes.
- Move To Component - move the code for a method to another class and invoke it
- Add Parameter - add a parameter to every implementor of a message, and to every invocation of the message (with a default value)
- Remove Parameter - if no implementor of the message uses the parameter, remove it from the methods and the invocations
- Cross referencing from inside the source code - select any program element in the text and you get a choice of several specialized browsers- senders/implementors of a message, readers/writers of a variable
- Rename - you can rename classes, variables (all types), and messages
- Abstract/Concrete Instance Variables - make all references to an instance variable go through a message, or make all references direct
With unlimited undo, you can bravely try experiments that might not pan out.