Refactoring Browser (Smalltalk)

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:

• integrated into the standard development tools e.g. the browser in Smalltalk
• must be fast. Smalltalk programmers are used to being able to immediately see the results of a change. ...Therefore, refactorings that take a long time to perform an analysis will not be used.
• avoid totally automatic reorganization. e.g. doesn't generate names (which would have no meaning in the user domain) but prompt for them

Another of the key design criteria is that we assume that there is an intelligence directing the refactoring process. ...It has been our experience that systems that perform automatic code reorganization are of little utility since they typically are algorithmic and have no understanding of the problem domain.

...

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:

• ...reflective facilities, that is, the ability for the language to examine and modify its own structures. ...Refactoring can be performed in the absence of reflective facilities, but then requires a separate, metalanguage that can be used to manipulate the original program. Having a single language simplifies the process.
• ...access to an easily manipulable representation of the program (e.g. the parse tree), which is provided by the VisualWorks environment; ...the transformations that refactorings require are much easier to implement as parse tree to parse tree transformations rather than string to string transformations. Other dialects of Smalltalk do not provide this level of access to the system, which is one of the major reasons the Refactoring Browser has not been ported to other environments.
• ...To ensure that the behavior of a program does not change, every refactoring has associated with it a set of preconditions that must be met in order to apply the transformation. ...

  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 Refactoring Browser uses method wrappers to collect runtime information. These wrappers are activated when the wrapped method is called and when it returns. ...As the program runs, the wrapper detects sites that call the original method. Whenever a call to the old method is detected, the method wrapper suspends execution of the program, goes up the call stack to the sender and changes the source code to refer to the new, renamed method. Therefore, as the program is exercised, it converges towards a correctly refactored program. ...

  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:

• the next step on the scale of refactorings are bigger ones which are composed of the well known basic refactorings which were first introduced by WILLAM OPDYKE [Opdyke, Thesis], the application of composite refactorings has the advantage that after performing one refactoring certain postconditions become true. These postconditions can be used without expensive analysis to satisfy preconditions of later refactorings. Therefore, refactorings are sometimes easier to perform in a composition than they are independently. Developing a system that incorporates these batch refactorings is currently being researched.
• Every creator of an API or open library has to deal with problems originating from the evolution of his product, which does also affect the interfaces to the outside world. The authors of the Refactoring Browser want to enable their users to have a partially automatic refactoring of older software to enable it to use the updated interface of the concerned API.

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:

• 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

Some other cool tricks:

• 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.