More-sophisticated behavior - Objects First with Java: A Practical Introduction Using BlueJ - page 181

This is the last change to the application discussed here in this chapter. The solution in the
project tech-support-complete contains all these changes. It also contains more associations of
words to responses than are shown in this chapter.

Many more improvements to this application are possible. We shall not discuss them here.
Instead, we suggest some, in the form of exercises, left to the reader. Some of these are quite
challenging programming exercises.

Exercise 5.40 Implement the final changes discussed above in your own version of the
program.

Exercise 5.41 Add more word/response mappings into your application. You could copy
some out of the solutions provided and add some yourself.

Exercise 5.42 Ensure that the same default response is never repeated twice in a row.

Exercise 5.43 Sometimes two words (or variations of a word) are mapped to the same
response. Deal with this by mapping synonyms or related expressions to the same string so
that you do not need multiple entries in the response map for the same response.

Exercise 5.44 Identify multiple matching words in the user's input, and respond with a more
appropriate answer in that case.

Exercise 5.45 When no word is recognized, use other words from the user's input to pick a
well-fitting default response: for example, words such as “why,” “how,” and “who.”

5.10 Writing class documentation

When working on your projects, it is important to write documentation for your classes as you
develop the source code. It is quite common for programmers not to take documentation seri-
ously enough, and very frequently this creates serious problems later.

Concept:

If you do not supply sufficient documentation, it may be very hard for another programmer (or
yourself some time later!) to understand your classes. Typically, what you have to do in that
case is to read the class's implementation and figure out what it does. This may work with a
small student project, but it creates serious problems in real-world projects.

The documenta-
tion of a class
should be de-
tailed enough for
other program-
mers to use the
class without the
need to read the
implementation.

It is not uncommon for commercial applications to consist of hundreds of thousands of lines of
code in several thousand classes. Imagine that you had to read all that in order to understand
how an application works! You would never succeed.

When we used the Java library classes, such as HashSet or Random , we relied exclusively on
the documentation to find out how to use them. We never looked at the implementation of those
classes. This worked because these classes were sufficiently well documented (although even
this documentation could be improved). Our task would have been much harder had we been
required to read the classes' implementation before using them.

In a software development team, the implementation of classes is typically shared between
multiple programmers. While you might be responsible for implementing the SupportSystem