One of a programmer’s favorite operations is „copy and paste“ which takes time to find all relevant locations and to repeat this operation (for example: 100 times) and can cause very strange errors just because at this time the developer does not realize the consequences of those changes.
A tool could help to refactor(see chapter 5.5) if programmers would try to use it!
- How to get a developer to refactor without „copy-and-paste“?
- What are the programmer’s expectations?
- Where is that super-tool for code transformation?
- Which problems need to be solved in order to develop a refactoring tool?
All these questions are also part of this research.
2.1 Support for code transformation
The idea of refactoring is beginning to enjoy widespread acceptance since costs for the evolution and maintenance of software make up to 70 percent of the software budget. In the 90's a large number of software was realized in object-oriented languages such as C++/Smalltalk and later Java. Object-oriented software is organized into classes and frameworks which provide modularity and enhance reusability. The first people who started popularizing refactorings were Kent Beck, Ralph Johnson and Bill Opdyke.
In the last couple of years several people have written good books[Bek97] about program transformations and how important refactorings for software design, upgrade and maintenance could be.
Most of those books end with the same statement: „One of the largest barriers to refactoring code has been the woeful lack of tool support for it“[Fowler99]
So far only a „Refactoring Browser“ for Smalltalk has been written to support the transformation of program code. Statically-compiled languages such as C++/Java are waiting for a good refactoring tool. We hope this research and the free availability of DPT as a prototype for the refactoring-tool will contribute some ideas and experience towards the development of commercial support for refactoring in common software developing environments for statically compiled languages.
The object-oriented design methods offer important opportunities for the reduction of maintenance and evolution costs. Language features such as inheritance, interfaces also contribute to reuse and extend existing classes. New UML-tools such as Rational Rose or STP increase the speed for design of object-oriented software.
But sometimes programmers(and also consultants) get too carried away:
They start making the classes too small(e.g. one method - one class!), for every class they define an abstract super-class, an interface and a factory-class. They start thinking about the future program extensions which will never happen and just loose too much expensive time. Instead of increasing the speed of program development, this kind of misuse of object-oriented design slows down the productivity and inflates the budget of the project.
Refactorings provide a new view of object-oriented program development:
- All future program changes can be done later (if the change is really required!) and can be supported by refactorings.
2.2 First Example
At this point it is customary to count all the benefits(see section 6.2) of refactorings. Instead, we would like to continue with an example which will show the practical use of refactorings. This example is a part of the DPT-tool and can be performed by users.
For the description of a transformation in examples, the following scheme will be used:
- Name and short information about transformation
- Start- and end- state (UML-diagram)
- Actual parameters of transformation
Note: For a complete definition and preconditions of each transformation see chapter 4
2.2.1 Program description
The welcome-program is a simple car-lifecycle simulation program written in Java. It creates a BMW3 car with BMW3 tires and a BMW3 engine, and lets this car drive until the car is a wreck. During the drive, the tires are rotated and changed and the engine is replaced. This program works only for a BMW3 car.
- Program-files(see appendix C):
AppMain.java - Contains main function, creates and runs a new application frame.
AppFrame.java - Class contains GUI-Components. Creates and drives a BMW-3 car.
Car.java - Class Car(BMW3) contains tires and engine and calls to their methods
HelpBox.java - Dialog that displays help-information.
BMW3_Tire.java - Contains concrete class tire for a BMW3 car
BMW3_Engine.java - Contains concrete class engine for a BMW3 car
- New requirements for car-simulator:
a) Next the BMW3 will be built with a new type of engine/tire (Program extension)
b) A manager decides to use this program to simulate other cars.(Reuse of the program)
!-- *** -->