This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Posted by Andrae Muys on August 07, 2000 at 12:22 AM
> But your point is how do you communicate the
> dependencies to other programmers? Just expressing
> the dependencies correctly in the code of the
> methods may still leave later readers of the code
> in the dark as to how the fields are being used.
In hardware synchronous state machines have three
components (well in theory anyway :)
Current State: Generally a register that stores the
Next State-Logic: Where the System's Inputs are
combined with the "Current State" in a bitwise boolean
operation that generates the bit-pattern that represents
the next state. This is then stored in the current state
Output Logic: A set of boolean logic circuits (one for each
output bit) that generates the output's logic level from
the "Current State".
In a simple state machine the bits that form the current
state ARE the output bits. However normally the output logic
is reasonably complex.
The key to this issue is that our coffee cup's current state
register (ie. instance variables) don't map 1:1 to our outputs
(ie. our classes state-view methods).
I feel it is obvious that we will have to document the
state->output mapping somewhere, the question is where.
Personally I document the valid states of my classes in the
classes javadoc, and the state->output mapping in its state-view
This of course dosn't solve the problem of what to do when
using a state variable as a temporary variable. Of course
when phrased like that it suggests that maybe you shouldn't
be doing that in the first place.
"Doctor it hurts when I do that".