Chapter 2
Motivation
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)