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

6.1 Introduction

It is possible to implement an application and get it to perform its task with badly designed
classes. Just executing a finished application does not usually indicate whether it is well struc-
tured internally or not.

The problems typically surface when a maintenance programmer wants to make some changes to
an existing application. If, for example, a programmer attempts to fix a bug or wants to add new
functionality to an existing program, a task that might be easy and obvious with well-designed
classes may well be very hard and involve a great deal of work if the classes are badly designed.

In larger applications, this effect occurs earlier on, during the original implementation. If the
implementation starts with a bad structure, then finishing it might later become overly com-
plex, and the complete program may either not be finished, or contain bugs, or take a lot longer
to build than necessary. In reality, companies often maintain, extend, and sell an application
over many years. It is not uncommon that an implementation for software that we can buy in a
software store today was started more than ten years ago. In this situation, a software company
cannot afford to have badly structured code.

Because many of the effects of bad class design become most obvious when trying to adapt or
extend an application, we shall do exactly that. In this chapter, we will use an example called
world-of-zuul , which is a simple, rudimentary implementation of a text-based adventure game.
In its original state, the game is not actually very ambitious—for one thing, it is incomplete.
By the end of this chapter, however, you will be in a position to exercise your imagination and
design and implement your own game and make it really fun and interesting.

world-of-zuul Our world-of-zuul game is modeled on the original Adventure game that was
developed in the early 1970s by Will Crowther and expanded by Don Woods. The original game is
also sometimes known as the Colossal Cave Adventure . This was a wonderfully imaginative and
sophisticated game for its time, involving finding your way through a complex cave system, locat-
ing hidden treasure, using secret words, and other mysteries, all in an effort to score the maximum
number of points. You can read more about it at sites such as http://jerz.setonhill.edu/
if/canon/Adventure.htm and http://www.rickadams.org/adventure/ , or try doing a
web search for “Colossal Cave Adventure.”

While we work on extending the original application, we will take the opportunity to discuss aspects
of its existing class design. We will see that the implementation we start with contains examples of
bad design, and we will be able to appreciate how this impacts on our tasks and how we can fix them.

In the project examples for this topic, you will find two versions of the zuul project: zuul-bad
and zuul-better. Both implement exactly the same functionality, but some of the class structure
is different, representing bad design in one project and better design in the other. The fact that
we can implement the same functionality in either a good way or a bad way illustrates the fact
that bad design is not usually a consequence of having a difficult problem to solve. Bad design
has more to do with the decisions that we make when solving a particular problem. We cannot
use the argument that there was no other way to solve the problem as an excuse for bad design.

So, we will use the project with the bad design so that we can explore why it is bad and then
improve it. The better version is an implementation of the changes we discuss here.