Well-behaved objects - Objects First with Java: A Practical Introduction Using BlueJ - page 258

Figure 7.7
Informal tabulation
of an object's state

Method called displayValue leftOperand previousOperator

initial state 0 0 ' '

clear 0 0 ' '

numberPressed(3) 3 0 ' '

This technique makes it quite easy to check back if something appears to go wrong. It is also
possible to compare the states after two calls to the same method.

1 As we start the walkthrough of CalcEngine , we document the initial state of the engine,

as in the first row of values in Figure 7.7. All of its fields are initialized in the constructor.
As we observed when walking through the tester, object initialization is important, and we
might make a note here to check that the default initialization is sufficient—particularly as
the default value of previousOperator would appear not to represent a meaningful op-
erator. Furthermore, this might make us think about whether it really is meaningful to have
a previous operator before the first real operator in a calculation. In noting down these ques-
tions, we do not necessarily have to try to discover the answers right away, but they provide
prompts as we discover more about the class.

2 The next step is to see how a call to clear changes the engine's state. As shown in the

second data row of Figure 7.7, the state remains unchanged at this point because display-
Value is already set to 0. But we might note another question here: Why is the value of only
one of the fields set by this method? If this method is supposed to implement a form of reset,
why not clear all of the fields?

3 Next, a call to numberPressed with an actual parameter of 3 is investigated. The method

multiplies an existing value of displayValue by 10 and then adds in the new digit. This
correctly models the effect of appending a new digit onto the right-hand end of an existing
number. It relies on displayValue having a sensible initial value of 0 when the first digit
of a new number is entered, and our investigation of the clear method gives us confidence
that this will be the case. So this method looks all right.

4 Continuing to follow the order of calls in the testPlus method, we next look at plus .

Its first statement calls the applyPreviousOperator method. Here we have to decide
whether to continue ignoring nested method calls or whether to break off and see what it
does. Taking a quick look at the applyPreviousOperator method, we can see that it
is fairly short. Furthermore, it is clearly going to alter the state of the engine, and we shall
not be able to continue documenting the state changes unless we follow it up. So we would
certainly decide to follow the nested call. It is important to remember where we came from,
so we would mark the listing just inside the plus method before following through the
applyPreviousOperator method. If following a nested method call is likely to lead to
further nested calls, we should need to use something more than a simple mark to help us
find our way back to the caller. In that case, it is better to mark the call points with ascending
numerical values, reusing previous values as calls return.

5 The applyPreviousOperator method gives us some insights into how the previous-

Operator field is used. It also appears to answer one of our earlier questions: whether
having a space as the initial value for the previous operator was all right. The method