Avoiding Mistakes

Modules

When solving problems in previous chapters, we have written pseudocode to describe the steps in our solution. Each step often can be described by a sequence of even smaller steps, and these steps eventually will correspond to pieces, or modules, of our Java program. A module might be a class or, more likely, a method.

Example

We have seen that the definition of a method can consist of calls to several other, often private, methods. For example, the class Temperature in the previous chapter has the following public method convertToFahrenheit that calls two private methods:

/** Converts the temperature to Fahrenheit. */
public void convertToFahrenheit()
{
   switch (scale)
   {
      case C:
         convertCelsiusToFahrenheit();
         break;
      case K:
         convertKelvinToFahrenheit();
         break;
      default:
         assert scale.equals(Scale.F);
         break;
   } // End switch
} // End convertToFahrenheit

The intent of these steps is clear. Because we used an enumeration for the temperature scale, we know that scale can only be C, K, or F.

The definitions of the two private methods are each short. For example, let’s recall the following one from the previous chapter:

 // Converts a Kelvin temperature to Fahrenheit.
private void convertKelvinToFahrenheit()
{
    assert scale.equals(Scale.K) : "Unexpected scale: not Kelvin";
    convertKelvinToCelsius();
    convertCelsiusToFahrenheit();
} // End convertKelvinToFahrenheit

The conversion from Kelvin to Fahrenheit converts the Kelvin temperature to Celsius first and then to Fahrenheit. Rather than risking algebraic errors in converting directly from Kelvin to Fahrenheit, we call two private methods that each perform simple arithmetic.