Thinking in Patterns chapter 18: Complex system states

Thinking in Patterns with Java V0.9: chapter 18: Complex system states: TIPatterns.htm#_Toc41169778

1, Sections:

Complex system states  159

  StateMachine. 159

    Exercises. 169

  Table-Driven State Machine. 169

    The State class. 171

    Conditions for transition. 172

    Transition actions. 172

    The table. 172

    The basic machine. 173

    Simple vending machine. 174

    Testing the machine. 179

  Tools. 180

  Table-driven code: configuration flexibility  180

    Table-driven code using anonymous inner classes  180

  Exercises. 180

2, The main content and feeling:

 

  Although I have been stopped at this chapter and State chart Diagram in UML

two or three days, there are still some questions left. But, I can't stay here

too long, there are many need to read, so, left some questions here, maybe

they will be resolved in the "future".

First of all, I found there isn't a pattern called "StateMachine Pattern" in

GoF's book except a pattern called "state pattern". Maybe, this is a design pattern invented by Bruce, just like the words below:

This method not only moves to the next state, but it also calls run( ) for each state object ? thus you can see it?s an expansion of the idea of the State pattern, since run( ) does something different depending on the state that the system is in.

What is Bruce's "StateMachine Pattern"?

He tells us:

While State has a way to allow the client programmer to change the implementation, StateMachine imposes a structure to automatically change the implementation from one object to the next.

There are two types of "StateMachine Pattern" implementation in this book.

The first is called "StateMachine" simplily, and second is called "Table-Driven State Machine". When I read these two "statemachine", I compared them with the State chart Diagram in UML I have learned before. So I found some question I can't answer. Below is my understanding for these two Bruce's StateMachine.

At first, give my understanding about State chart Diagram in UML, I like its

OOP style, even I maybe missunderstood it, I put my understanding here, wish

someone can point out my error.

A State chart Diagram can be owned by an entity(for example, an object of a

class ), if the entity's action dependents on what state the entity is in, then a state chart diagram may be needed.

For me, the most important understanding about this is the transition between

two states. Three things can be in a transition: event, just a call to this

object's method or a message send to this object; guard condition, only it is

"true" can event cause a state's change; action, just some processes in

object's method or some messages send to other objects to perform somethings during this transition.

Then, bring the idea of UML's state chart diagram in my mind, I look at Bruce's first "StateMachine".

In this statemachine, all is focus on the state class. state class performace

some actions in the transition SHOULD before this state, state class recieve an input

and decide which state is the next state.

Just like below:

public interface State {   void run();   State next(Input i); } ///:~

Why do I say "state class performace some actions in the transition SHOULD before this state"?

Because I read some in this book like below:

and as that transition is made some kind of action occurs (in the previous state machine design, this was the run( ) method):

I try to model the example of "statemachine" with UML's state chart diagram,

but I failed. Because the state object has done all the things, and the owner of

state objects has nothing to do. I can't send the owner a message which should

be a method of the owner to make a transition!

And another question in the example is:

class Waiting implements State {   public void run() {     System.out.println(       "Waiting: Broadcasting cheese smell");   }   public State next(Input i) {     MouseAction ma = (MouseAction)i;     if(ma.equals(MouseAction.appears))       return MouseTrap.luring;     return MouseTrap.waiting;   } }

Why is "Waiting: Broadcasting cheese smell" in the run() method, but not

"Wait: Broadcast cheese smell"? Does it indicate a state or an action during transition before this state? I am a little confusing.

And, from the State chart diagram's definition, an action should be occured

before current state appeared in this example, but I don't know why it happens

as a run() method in a state object, just like below:

public final void runAll(Iterator inputs) {     while(inputs.hasNext()) {       Input i = (Input)inputs.next();       System.out.println(i);       currentState = currentState.next(i);       currentState.run();     }

Next, from section "Table-Driven State Machine" I can draw example's State

chart Diagram using UML tool.

In this example, the state class can't do something like above's example, and,

an object called stateMachine holds every thing. I can send this stateMachine

a message: nextState(input: Input), this just a event cause the state's

change; And, when this transition is made, an action occurs by nextState()

to call another object's method: Transition.transition(input: Input), or the

stateMachine object just send a message to trasition object to do some actions.

Maybe, this just is the meaning of Bruce's words: "The classic state-transition diagram".

Maybe, Bruce's statemachine is from the aspect of using purpose, all these examples are focusing on how to design a statemachine conveniently; But I focus on if these "statemachine" are real "StateMachine" defined in UML.

Maybe, I have misunderstood all the UML's "statemachine" and the

"statemachine" in this book's example. If any of these case, please give me a

hint. My english is also very poor, if there are some thing unclear, please

let ne know. Thanks.

3, Questions about programming:

Many questions has been written above. Except above, There are entire section

I can't understand just below:

(Simple State Machine Diagram) Goals: ·         Direct translation of state diagram ·         Vector of change: the state diagram representation ·         Reasonable implementation ·         No excess of states (you could represent every single change with a new state) ·         Simplicity and flexibility Observations: ·         States are trivial – no information or functions/data, just an identity ·         Not like the State pattern! ·         The machine governs the move from state to state ·         Similar to flyweight ·         Each state may move to many others ·         Condition & action functions must also be external to states ·         Centralize description in a single table containing all variations, for ease of configuration Example: ·         State Machine & Table-Driven Code ·         Implements a vending machine ·         Uses several other patterns ·         Separates common state-machine code from specific application (like template method) ·         Each input causes a seek for appropriate solution (like chain of responsibility) ·         Tests and transitions are encapsulated in function objects (objects that hold functions) ·         Java constraint: methods are not first-class objects

And, I almost can't see the picture after this section.

4, Questions about english language:

1), Strange words:

  impose, tagging, conceivably, mousetrap, theWhiW,

2), Strange sentences:

 // A State has an operation, and can be moved

 // into the next State given an Input:

This is typical, but certainly not required ? you could concievably want to override it, but typically the behavior change will occur in State?s run( ) instead.

   incomplete