Advertisement

Viewing objects as finite state machines
One way to think of objects is as finite state machines. Thinking of objects in this way as you design classes can help you acquire a mindset that is conducive to good object design.

For example, one finite state machine is a simple traffic light that has three states: red, yellow, and green. A state transition diagram for such a traffic light is shown in Figure 1 (a Java applet).

You need a Java-enabled browser to see this applet. State-transition diagram for a traffic light

In Figure 1, states are represented by labeled circles, state changes by arrows, and events by labels next to the arrows. When the finite state machine experiences an event, it responds by performing the state change indicated by the arrow.

The finite state machine shown in Figure 1 could be represented by instances of the following Java class. (As a matter of fact, the following class is used to represent the traffic light finite state machine in the Java applet that is Figure 1. Click here to view the full source code of the traffic light applet.)

public class TrafficLight {

    public static final int RED = 0;
    public static final int YELLOW = 1;
    public static final int GREEN = 2;

    private int currentColor = RED;

    public int change() {

        switch (currentColor) {

        case RED:
            currentColor = GREEN;
            break;

        case YELLOW:
            currentColor = RED;
            break;

        case GREEN:
            currentColor = YELLOW;
            break;
        }

        return currentColor;
    }

    public int getCurrentColor() {
        return currentColor;
    }
}

In class TrafficLight, the state of the object is stored in the currentColor private instance variable. A "change" event is sent to the object by invoking its public instance method, change(). State changes are accomplished through the execution of the code that implements the change() method.

As you can see from the TrafficLight example, Java objects map to finite state machines in the following ways:

• The range of possible values that can be stored in the object's instance variables map to the finite state machine's states

• An invocation of an object's instance method maps to a finite state machine receiving an event

• Executing an object's instance method maps to the state change that a finite state machine experiences as the result of an event

Most objects you design will have many more states than a TrafficLight object. Some objects will have instance variables whose ranges are limited only by available resources, such as memory, rendering objects that are practically "infinite state machines." But in general, it is helpful to think of objects as state machines and to design them accordingly.

The canonical object design
The TrafficLight class is an example of the generally accepted form of a basic object design. The object has state, represented by instance variables that are private. The only way that code defined in other classes can affect the object's state is by invoking the object's instance methods.

Because other classes don't have direct access to the currentColor variable, they can't screw up its value, such as by setting it equal to 5. (In this case, the only valid values for currentColor are 0, 1, and 2.) In addition, there is no way for a TrafficLight object to go directly from state YELLOW to state GREEN, GREEN to RED, or RED to YELLOW.

Given this design of class TrafficLight, a TrafficLight object will always have a valid state and will always experience valid state transitions -- from the beginning of its lifetime to the end.