In my previous project, I started with a simple design using a transition matrix. I must confess it didn't work well. It was hard to explain and it grew more complex as new requirements were added. I though it would be simpler if I didn't use any "fancy OO stuff" and advanced idioms. I've should know better!
This time I wanted to try something different, and based in my previous experiments with internal DSLs with Scala and my (very limited) knowledge of the patters to achieve that in java, I just went ahead and tried to come up with something useful and understandable. This time seems to be working: although it has some "magic" behind curtains is only in the creation and is very easy to add or modify the configuration class for new or updated states and events. Other members of my project were able to add and remove states and transitions with only a brief explanation.
The basic classes are pretty simple: State and Event.
package statemachine;
public class Event {
final private String label;
public Event(String newLabel){
label=newLabel;
}
/**
* @return Returns the label.
*/
public String getLabel() {
return label;
}
public String toString(){
return label;
}
}
package statemachine;
import java.util.HashMap;
import java.util.Map;
public class State {
private final String label;
private final Map<Event,Transition> transitions= new HashMap<Event,Transition>();
//no public access to the constructor, must be in the same package
State(String newLabel){
this.label=newLabel;
}
void addTransition(Transition t){
transitions.put(t.getEvent(),t);
}
public State doEvent(Event e){
return (transitions.get(e)).getDestination();
}
/**
* @return Returns the label.
*/
public String getLabel() {
return label;
}
/**
* @return Returns the transitions.
*/
public Map<Event,Transition> getTransitions() {
return transitions;
}
}
You send a event to a sate and it returns the next state:
State newState=state.doEvent(event);
The State class holds a map of [event->state] (with the Transition class in the middle, for added effect :) )
As an extra safety measure, the State constructor and the addTransition method is accessible only to the package (well, unless you subclass it)
The "fluency" is provided by the Transition class (the useful methods return this to allow method chaining), so you can write:
new Transition(event).from(origin).to(destination)
package statemachine;
class Transition {
private State origin,destination;
private Event event;
public Transition(Event e){
event=e;
}
public Transition from(State orig){
origin=orig;
origin.addTransition(this);
return this;
}
public Transition to(State dest){
destination=dest;
return this;
}
/**
* @return Returns the destination.
*/
public State getDestination() {
return destination;
}
/**
* @return Returns the event.
*/
public Event getEvent() {
return event;
}
/**
* @return Returns the origin.
*/
public State getOrigin() {
return origin;
}
}
How this will look? Suppose you have a pretty simple FSM:
Using the previous pseudoDSL/Fluent interface will look like:
package statemachine;
public class FSMDef {
public final static State SUBMITTED=new State("Submitted");
public final static State OPEN= new State("Open");
public final static State CANCELLED= new State("Cancelled");
public final static State CLOSED= new State("Closed");
//Events
static class Events {
public final static Event OPEN = new Event("Open");
public final static Event CLOSE = new Event("Close");
public final static Event REOPEN = new Event("Re-Open");
public final static Event CANCEL = new Event("Cancel");
}
static {
new Transition(Events.OPEN).from(SUBMITTED).to(OPEN);
new Transition(Events.CLOSE).from(OPEN).to(CLOSED);
new Transition(Events.REOPEN).from(CLOSED).to(OPEN);
new Transition(Events.CANCEL).from(OPEN).to(CANCELLED);
}
}
Doesn't seems too complex, right?
I'm just starting with this, and probably barely skim the surface (sure it has some drawbacks), but so far it worked :)
[EDIT: Fixed the generics declarations that were eaten by the HTML format. BTW, if anybody knows a good code formatter for blog posts, let me know ]
