Designing classes - Objects First with Java: A Practical Introduction Using BlueJ - page 223

It is tempting for a maintenance programmer to add some extra code to existing classes or
methods. Doing this for some time, however, decreases the degree of cohesion. When more and
more code is added to a method or a class, it is likely that at some stage it will represent more
than one clearly defined task or entity.

Refactoring is the rethinking and redesigning of class and method structures. Most commonly,
the effect is that classes are split in two or that methods are divided into two or more methods.
Refactoring can also include the joining of multiple classes or methods into one, but that is less
common than splitting.

6.12.1 Refactoring and testing

Before we provide an example of refactoring, we need to reflect on the fact that, when we
refactor a program, we are usually proposing to make some potentially large changes to some-
thing that already works. When something is changed, there is a likelihood that errors will be
introduced. Therefore, it is important to proceed cautiously; and, prior to refactoring, we should
establish that a set of tests exists for the current version of the program. If tests do not exist, then
we should first decide how we can reasonably test the functionality of the program and record
those tests (for instance, by writing them down) so that we can repeat the same tests later. We
will discuss testing more formally in the next chapter. If you are already familiar with automated
testing, use automated tests. Otherwise, manual (but systematic) testing is sufficient for now.

Once a set of tests has been decided, the refactoring can start. Ideally, the refactoring should
then follow in two steps:
■ The first step is to refactor in order to improve the internal structure of the code, but without
making any changes to the functionality of the application. In other words, the program should,
when executed, behave exactly as it did before. Once this stage is completed, the previously
established tests should be repeated to ensure that we have not introduced unintended errors.

■ The second step is taken only once we have reestablished the baseline functionality in the re-
factored version. Then we are in a safe position to enhance the program. Once that has been
done, of course, testing will need to be conducted on the new version.

Making several changes at the same time (refactoring and adding new features) makes it harder
to locate the source of problems when they occur.

Exercise 6.27 What sort of baseline functionality tests might we wish to establish in the
current version of the game?

6.12.2 An example of refactoring

As an example, we shall continue with the extension of adding items to the game. In Section 6.11.2,
we started adding items, suggesting a structure in which rooms can contain any number of items.
A logical extension to this arrangement is that a player should be able to pick up items and carry
them around. Here is an informal specification of our next goal:

■ The player can pick up items from the current room.
■ The player can carry any number of items, but only up to a maximum weight.