5

I have a state machine with many states A--B--C--D--E. I have many transitions from C for example to A if some condition is verified. For every state I have a class extending abstract class Stateand I have a manager that delegates every transition method to state method. The question is "could states call directly manager transition methods?". I have seen on Internet only examples in which there is a main class that knows exactly how many times transition happens (i.e. insertQuarter(), ejectQuarter(), turnCrank(), dispense()). The only way I found to do this is to call manager transition methods in states. Is this wrong or bad practice?

Thanks in advance Tobia

jaco0646
  • 15,303
  • 7
  • 59
  • 83
Matroska
  • 6,885
  • 14
  • 63
  • 99

2 Answers2

3

If you need a simple synchronous state machine, where at most one execution takes place at any given point in time, the model I'm thinking of is as follows:

1) A context of the execution is represented by a Context object. The context is passed between the states, and it is used for flow decisions by the manager. The API of the context depends on how generic you need the system to be.

2) State interface contains the execute(Context) method, where the specific logic takes place. It is allowed to use and change the context data.

3) The manager is configured with the transition rules. It is able of determining the next state to execute, given the last state and the context. It starts by executing the initial state. After each execution of state S it checks the context object against the transition rules associated with the state S. When it reaches a terminal state, the flow is over.

With this design, the state implementations are not aware of the manager in any way, and are not involved in routing decisions.

Eyal Schneider
  • 22,166
  • 5
  • 47
  • 78
  • but with your suggestion, state pattern isn't used since states don't decide next states. Right? – Matroska Jun 10 '10 at 14:34
  • @Matroska: The idea of the state design pattern as I understand it, is to store a reference to some execution mechanism, and delegate commands to it. The executor can be replaced at any time, when behavior change is needed. In the design I proposed, I believe that the manager uses the pattern, since it stores a reference to the current state, and changes this reference after every transition. – Eyal Schneider Jun 10 '10 at 14:58
  • @Matroska: I agree that my approach is different than Wikiperia's example. However, I think it is a cleaner way for implementing a state machine. The states don't have to know about each other. – Eyal Schneider Jun 10 '10 at 15:42
  • I am starting thinking there is no other cleaner way. Thanks – Matroska Jun 10 '10 at 17:39
0

Yes... At least if I understood your question correctly. The manager has to keep a reference to the current state, so the current state must be able to ask the manager to move to the next current state. Look at the Wikipedia example for an example.

pgras
  • 12,614
  • 4
  • 38
  • 46
  • I can ask the manager to move to another state setting the current state to the next one...but then how to activate the next state? In the wiki example, there isn't my situation. It would be the same if I put stateContext.writeName(String name) into the writeName method of one of the states (after setting it) – Matroska Jun 10 '10 at 17:38
  • You don't 'activate' the next state. Switching to it means telling the manager (context) that its state is now NextState. When the context needs to do some action, it delegates it to its state with its implementation of the method. – Noich May 07 '13 at 07:36